cns planning and implementation in the mid region atm … sg8/cns sg8-wp12- … · navigation and...

CNS SG/8-WP/12 17/1/2018

International Civil Aviation Organization

MIDANPIRG Communication, Navigation and Surveillance Sub-Group

Eighth Meeting (CNS SG/8)

(Cairo, Egypt, 26 - 28 February 2018)

Agenda Item 4: CNS Planning and Implementation in the MID Region

ATM DATA SECURITY IN THE MID REGION

(Presented by UAE)

SUMMARY

The aim of this paper is to present the proposed Minimum Security

Baseline documents (MSB’s), which form part of the ATM Data

Security Action Group’s deliverables to the MIDANPIRG 1, as well as

the proposed portal that has been developed to facilitate the sharing of

knowledge and reporting of cyber events.

Action by the meeting is at paragraph 3.

REFERENCES

- ED 153 – Guidelines for ANS software safety assurance.

- ISO 27002 Information Security

ED 109A – Software integrity assurance considerations for CNS

and ATM systems.

- MIDANPIRG/16 Report

1. INTRODUCTION

1.1 The meeting may recall that MIDANPIRG/16, through Decision 16/26, agreed that the

establishment of a MID Region ATM Data security action group was required to establish a baseline

security plan for ATM data services within the MID Region.

CNS SG/8-WP/12 -2-

DECISION 16/ 26: ATM DATA SECURITY ACTION GROUP

That, the ATM Data Security Action Group (ADSAG) be:

a) established to develop the MID Region ATM Data Security Plan, to be

presented to the CNS SG/8; and

b) composed of members from Bahrain, Iran, Kuwait, Oman, Saudi Arabia, UAE

(Rapporteur), ICAO and IFAIMA

2. DISCUSSION

2.1 As per the MIDANPIRG Decision 16/26 the establishment of a MID Region ATM Data

security action group was required to establish a baseline security plan for ATM data services.

2.2 Security within the current ATM systems is very limited and while many systems are

isolated from the internet the risks faced by them are no different as an offline system can be

compromised just as easily.

2.3 More and more internet based services are being required by ANS units and along with

the future SWIM requirements we need to ensure that we have a robust, scalable security plan, not only

in place but implemented throughout the region for harmonized air traffic service provision.

2.4 Security requirements do generally require substantial financial investment however

no amount of money can truly protect a system from being compromised and therefore the ATM Data

security plan should be developed in such a way that, while some financial investment will still be

required, it is affordable and implementable to all the MID Region States.

2.5 To try and ensure that such a plan can be implemented, we have developed the draft

Minimum Security Baseline Documents (MSB’s) which, if endorsed, will form the backbone of the

Mid ATM Data Security plan. These documents have been developed based on current best practices

and aligned to suit our daily operational requirements.

2.6 The MSB’s consist of 7 documents and are the MINIMUM suggested security

requirements for the respective services/technologies. The documents are as follows:

- Web Application security baseline

- Linux security baseline

- Switch security baseline

- Web Application Firewall baseline

- Firewall security baseline

- Router security baseline

CNS SG/8-WP/12 -3-

2.7 The MSB’s is at Appendix A.

2.8 As mentioned, the requirements laid out in these documents are based on current best

practices and while these are in no way the final solution for all, for the most part these are solutions

that can be implemented with minimal impact to the daily operations and service provision.

2.9 Having these baselines in place will provide us as ANSP’s, a solid foundation to further

enhance our security policies and procedures. These documents are intended to be living documents

and should be reviewed at a minimum of once a year to ensure they remain valid.

2.10 As an additional tool for the ANSP’s within the MID Region, we are currently

developing an online portal that will provide us a database of known attacks/threats as well as provide

us reporting mechanism for cyber events. This portal will also include a forum whereby registered users

can discuss security related issues on a daily basis, thus allowing a greater sharing of knowledge and

better awareness amongst the MID States. The portal is planned to be fully functional by the end of

April 2018.

2.11 Additional ISO 27002 and EuroCAE requirements are also currently being looked at

to further enhance these baseline documents and will be added to the final documentation that is

presented to the MIDANPIRG later this year.

3. ACTION BY THE MEETING

3.1 The meeting is invited to:

a) urge States to review, the MSB’s and provide feedback before the end of April to

form a security plan to be presented at MIDANPIRG 17; and

b) once available, States are urged to register on the ATM data and cyber security

portal and provide feedback for further enhancements.

-------------

MSB | WAS | V0.2 Issue Date: 01/ 2018

Page 1 of 15

CNS SG/8-WP/12

APPENDIX A

Minimum Security Baseline Document

Web Application Security

MSB-WAS V0.2


Page 2 of 15

Document Control Signing in the respective section below confirms that you have read the document fully and approve its contents.

Issue

Version Date Author Accountable Manager Signature

V0.1 26/11/2017 GCAA – UAE

V0.2 31/01/2018 GCAA-UAE

Reviewers

Version Date Name Designation Signature

Approvals


Distribution

Section Copy To (Name) Designation

Amendments

Version Date Reference

Section Amendment Content

Author: refers to the individual who carried out the initial task of preparing or revising the document.

Reviewer: refer to the individual(s) who took part in assessing, providing comments and endorsing the changes to the document.

Approver: refer to the individual(s) with the authority to approve the document so that it can be issued and implemented.


Page 3 of 15

TableofContents

1. Introduction............................................................................................................................................ 4

2. References ............................................................................................................................................ 4

3. Abbreviations and Acronyms ................................................................................................................ 4

4. Change Management ............................................................................................................................ 5

5. Responsibilities and Roles .................................................................................................................... 5

6. MSB Directives ...................................................................................................................................... 5

5.1 Privacy and Regulations ............................................................................................................... 5

5.2 User registration / Password Management ................................................................................... 5

5.3 Login and User Authentication ...................................................................................................... 7

5.4 Access Control and Authorization ................................................................................................. 8

5.5 Session Management ................................................................................................................... 8

5.6 Cryptographic Key Management ................................................................................................... 9

5.7 Data Confidentiality ..................................................................................................................... 10

5.8 Data Integrity ............................................................................................................................... 11

5.9 User Input and Validation ............................................................................................................ 11

5.10 Content and Links ....................................................................................................................... 12

5.11 Exception Handling and Logging ................................................................................................ 12

5.11 Server Configuration ................................................................................................................... 13

5.12 Architecture ................................................................................................................................. 14

5.13 Operation ..................................................................................................................................... 14


Page 4 of 15

1. Introduction

This document details the Minimum Security Baselines for ANSP Web Applications hosted internally and

externally. The supplier/developer shall use this baseline control document for configuration of Web

Applications and Web Servers to ensure the deployment of industry best practices.

Any type of Web Application shall be designed but not limited to ensure the compliance of this document.

2. References

ICAO Annex 17

ICAO Doc 9985

EuroCAE ED – 109A - Software Integrity Assurance Considerations for Communication and

Navigation and Surveillance and Air Traffic Management (CNS/ATM) Systems

EuroCAE ED – 153 - Guidelines for ANS Software Safety Assurance

3. Abbreviations and Acronyms BASH UNIX Shell Command

CSRF Cross Site Request Forgery

LDAP Light Weight Directory Access Protocol

MSB Minimum Security Baseline

NTLM Windows Authentication

PIN Personal Identification Number

RPC Remote Procedure Call

SLDAP Secured LDAP Protocol

SOAP Simple Object Access Protocol

SSL Secured Socket Layer

TLS Transport layer Security


Page 5 of 15

4. Change Management

The change or modification of any of the services and infrastructure mentioned in this document shall

follow a detailed change management process in compliance with the respective regulatory requirements

of that state

5. Responsibilities and Roles

CNS Departments are responsible for implementing and maintaining the MSB defined in this document.

This document shall be reviewed:

Annually,

Depending on changes incorporated in the environment

6. MSB Directives

This document is intended to guide the developer to secure the Web applications from external threats,

attacks and unauthorized access. CNS/Supplier shall use this baseline control document, as a minimum,

while deploying Web Applications and Web Servers.

Following the below guidelines should assure the (best possible) secure environment for web applications

and would assist ANSP’s to prevent external intrusions to the best possible extent.

5.1 Privacy and Regulations

The users’ privacy shall be maintained in accordance with the privacy regulations and policies

applicable to the data.

If the application is not explicitly “opt-in”, there shall be written procedures for handling of “opt-out”

requests.

The application shall not use, store, or transmit any portion of the user’s birth date.

5.2 User registration / Password Management

User self-registration shall follow a two-step validation process, with the first step being identification,

and the second step being returning to the site with a temporary password sent to that identified user’s

address. If the two-step validation process is not used, then self-registration process shall be approved

by the ANSP.


Page 6 of 15

Users shall be able to only register once, and shall not be allowed to reregister. Usernames shall be

checked for uniqueness.

Usernames/userids shall be case insensitive. Example user “smith” and user “SmiTh” shall result in

same username/userid.

Applications shall not be susceptible to username harvesting.

Applications shall not use generic or shared accounts.

All passwords (initial password, reset password, user changed password) shall comply with password

policies. This includes passwords for users, administrators, database access, operating systems, and

any other services. The policy states that password complexity shall be at least 8 characters in length,

and have at least one uppercase letter, one lowercase letter, and one number.

Applications shall enforce password-aging policies, which states that user passwords must be changed

every 90 days (at a minimum), and administrator passwords must be changed every 45 days (at a

minimum).

Password history rules shall be implemented to prevent reuse. When possible, at least 3 previous

passwords shall be remembered.

Users shall be given a mechanism to change their passwords.

When the user changes their password, it shall not be allowed to be the same as the existing password.

Passwords shall be stored as hashed values with a “salt” value, this will prevent rainbow table attacks.

The salt value itself shall be pseudo random and cryptographically strong.

If a user forgets their password, they shall not be allowed to recover the existing password.

Password reset methods (online or admin-assisted) shall be secure. All methods of password resets

shall be documented.

A reset password shall be a dynamically generated random password, and shall not be valid for more

than 24 hours.

When sending password (initial or resets) through e-mail, it shall be a onetime use password.

When sending password through e-mail, it shall be sent through encrypted e-mail.

The user shall be forced to change their password when they login the first time with initial password

or after a password reset.


Page 7 of 15

5.3 Login and User Authentication

In authentication, application shall allow case insensitive usernames/userids.

Invalidate authentication ‘shortcuts’ by disallowing login without 2nd factors, secret questions or some

other form of strong authentication.

Disallow changes to user accounts such as editing secret questions and changing account multi-factor

configuration settings

Set ‘tainted’/‘compromised’ bit until user resets credentials

Anti-automation shall be in place to prevent breached credential testing, brute forcing, and account

lockout attacks

Forgotten password and other recovery paths shall use a TOTP or other soft token, mobile push, or

other offline recovery mechanism. Application shall not send a random value in an e-mail or SMS.

Application shall not use any external authorization service for protecting access to protected

resource(s).

The application shall not be susceptible to LDAP Injection, or that security controls prevent LDAP

Injection

Passwords, PINs, and other tokens used for authentication shall be protected during transit between

the client machine and server, as well as between all servers.

The access tokens shall have limited access.

Information about what constitutes a valid username or password shall not be provided to

unauthenticated users, such as on login screen, help pages, etc.

Login failure messages shall not indicate which of the username / password pair submitted was

incorrect.

Authentication and session data shall not be transmitted using HTTP GET, and shall use HTTP POST

instead.

After a maximum of 5 invalid logins attempts to a username, the application shall not allow that

username to log in for a minimum period of 10 minutes, even if the valid password is entered.

Applications shall not be susceptible to authentication circumvention.

Applications shall generate a unique session and/or token identifier upon a successful user

authentication. The session identifier shall be used to associate the user to the active session.

Applications shall not rely on any data stored on the client other than the session identifier for user

authentication.


Page 8 of 15

Challenge questions shall be selected from the pre-approved list of questions. Any variation from these

questions shall receive approval before use.

Challenge / response phrases shall not contain the user’s password.

Response phrases shall not be the same as their corresponding challenge question.

Application shall integrate with centralized LDAP/RADIUS for authentication wherever applicable

If user or application credentials are used during the bind to an LDAP directory, it shall be done using

Secure Sockets Layer (SSL) encryption of LDAP (SLDAP) over port 636.

Application shall not use windows NTLM for authentication until approved by the ANSP. In case of

certificate based authentication of client/user refer to the section “Cryptographic Key Management”

5.4 Access Control and Authorization

The server shall enforce access control for each site function.

Applications shall not be susceptible to authorization circumvention.

Applications shall rely solely on the session and/or token identifier to associate the user and the

authorization. Applications shall not rely on other values sent from the client system for determination

of authorization level.

Access to the source code shall be tightly controlled, and supplied only on an as-needed basis.

Application shall whitelist allowable methods (HTTP GET, POST, PUT, DELETE) for a service.

Application shall enforce context sensitive authorization so as to not allow unauthorized manipulation

by means of parameter tampering

For sensitive application features, application shall use strong transaction authentication by using a

second factor to check whether the user is authorized to perform this function.

5.5 Session Management

Sessions shall not be subject to hijacking. Session IDs and other tokens used for identification shall be

protected during transit.

Session IDs shall use strong, non-predictable algorithms.

Session state shall be maintained on the server, and be associated with a single client using a session

ID.


Page 9 of 15

Session state shall be tied to a specific browser session using a session cookie.

Session state shall not be stored in a persistent cookie or web local storage or web database.

Applications shall not rely on hidden fields for maintaining session state.

Sessions shall expire after a maximum of 10 to 15 minutes of inactivity.

Sessions shall expire after a maximum of 8 to 12 hours of activity.

Sessions shall not be allowed to span both secure and non-secure connections.

Users shall be given a means to explicitly terminate their session, such as with a “logout” button.

Applications shall not allocate session identifiers and other resources for unauthenticated users, which

can lead to denial of service attacks, session fixation attacks, and others.

Session cookies shall be configured to restrict distribution beyond the application.

5.6 Cryptographic Key Management

Cryptographic functions shall be selected from a list approved by Information Security Group. Any

cryptographic functions used that are not previously approved require an exception. Approved

algorithms (with minimum bit lengths), in order of preference, are:

Hashing: SHA-1, RIPEMD160 and MD5.

Symmetric: AES/Rijndael (128 bits), 3-DES, DES-CBC, Blowfish, Twofish, and IDEA.

Public key: RSA (minimum 1024 bit) and DSA(minimum 1024 bit).

Any use of hashing shall be salted. Values used for salting shall be protected.

Encryption keys shall be protected during transit and while stored in file system.

Encryption keys shall not be disclosed to anyone who does not need access to them.

If someone who possesses the encryption key is no longer required to have the key, it shall be

regenerated.

Site certificates shall be current and issued by a well-known certificate authority.

Application shall not allow low-grade encryption.

Application parameter values shall be encrypted and preferably hashing shall be used.

Application services shall be protected from Cross-Site Request Forgery. Two or more of the following:

ORIGIN checks, double submit cookie pattern, CSRF nonces, and referrer checks, shall be

implemented.


Page 10 of 15

Every web page within application shall generate Anti-CSRF random token to prevent forgery attacks

at application layer.

5.7 Data Confidentiality

If the system has a user authentication system, it shall only be accessible over SSL. Pages served

over the HTTP interface shall automatically send an HTTP 301 message to redirect the application to

its SSL counterpart.”

Only TLS V1.2 shall be enable and TLS V1.1, TLS V1.0, SSL V3, SSL V2 shall be disable.

Any sensitive content sent to the client machine shall not be cached. The application is responsible to

set the proper directive to cause the client to not cache the sensitive data.

Application shall not store any confidential information in a persistent cookie. Cookies shall be set with

the “secure” and “httpOnly” flag.

Application shall not present confidential information to unauthenticated users.

Application shall not store sensistive information in hidden fields.

Any sensitive data shall be sent encrypted.

Any highly confidential data shall be stored encrypted.

Confidential information shall be protected during transit, such as client-to-server communications, e-

mails, report generation, and automated transfers.

Any transmission / reception of data that is confidential or non-confidential, shall be sent/received over

secure channels, what so ever the protocol is used.

If the communication has to be done over non-secured channels, the data shall be encrypted and

signed. The recipient of the confidential data shall validate the authenticity of the signature.

Web application(s) shall not store any sensitive information in local web store or offline storage.

Web application(s) shall not store session identifiers in web storage alternatively known as local storage

or offline storage or in web databases

Functions shall not be allowed to be executed on both encrypted and non-encrypted connections. If

functions are required to exist on both encrypted and non-encrypted connections, then the user

sessions shall not be allowed to span both connections.


Page 11 of 15

5.8 Data Integrity

If data is supplied to the application from an authoritative source, the application shall not allow users

to modify this data.

User credentials shall be stored in a repository whose trust is commensurate with the confidentiality of

the data collected, accessed, and/or maintained by the application.

User credentials in one repository shall not be synchronized with any other repositories unless their

trust levels are equal.

Security Group shall approve any password synchronization.

The user credentials repository shall not be used by systems with lower security than the application.

5.9 User Input and Validation

All input content shall be validated by the server, and shall be validated to accept only values permitted

in accordance with the data dictionary. It is not secure to rely only on client-side validation.

All user input parameters shall not be susceptible to buffer overflows.

Web applications shall not be susceptible to cross-site scripting either stored or reflected. This includes

all headers, cookies, query strings, form fields and hidden fields.

Applications shall not be susceptible to SQL injection attacks, or other command injection flaws.

Query strings shall be obfuscated, so a user cannot perform ad-hoc queries.

In case of web services and rest services, XML or JSON schema shall be in place and verified before

accepting input and application must validate the input against the schema definition

Verify that all input is limited to an appropriate size limit.

The XSD, at a minimum, shall define the maximum length and character set of every parameter allowed

to pass into and out of the application.

The XSD shall define strong (ideally white list) validation patterns for all fixed format parameters (e.g.,

zip codes, phone numbers, list values, etc.).

In case of a malformed input, the application validator must stop executing the request, once a fatal

error is detected. The input shall not undergo any additional processing.


Page 12 of 15

5.10 Content and Links

Only the latest version of the production code shall be installed on the production servers.

Unnecessary or unauthorized links to other pages shall be removed.

Source code shall not be sent to an end user machine.

Comments in code sent to an end user machine shall be removed.

Any form submissions that send e-mail shall use static sender and recipient addresses, and shall

secure these addresses from modification.

5.11 Exception Handling and Logging

All errors, exceptions, and other error conditions shall be caught by the application and handled

appropriately. These internal error conditions shall not be displayed to the end user.

All log entries shall include the time of the event, the application associated with the event, the user or

initiating process, the remote IP address associated with the event, and a detailed description of the

event.

All valid and failed login attempts shall be logged with meaningful information that is actionable if fraud

is detected. However, passwords shall not be logged.

All authorization events shall be logged: Resources/functions being requested, resources/functions

being authorized and resources/functions being denied.

All other important events shall be logged such as session management failures, connectivity problems,

performance issues, third party service error messages, configuration changes, application and related

systems startup and shutdown, application errors and system events.

All password recovery or reset attempts shall be logged with meaningful information that is actionable

if fraud is detected.

All account lockouts shall be logged.

All security policy changes and attempts shall be logged.

All user and account management changes and attempts shall be logged.

Logging of debugging information shall be disabled on production systems.

Sensitive values such as passwords, even incorrect ones, shall not be logged in the log file.

If logs are stored in file system, use a separate partition than those used by the operating system, other

application files and user generated content


Page 13 of 15

For file-based logs, apply strict permissions concerning which users can access the directories, and

the permissions of files within the directories

In web applications, the logs shall not be exposed in web-accessible locations.

When using a database to store logs, utilize a separate database account that is only used for writing

log data and which has very restrictive database, table, function and command permissions.

Security logs shall have some form of integrity checking or controls to prevent unauthorized

modification.

All non-printable symbols and field separators are properly encoded in log entries, to prevent log

injection

There should be a system monitoring application that can set a threshold against the log file size and/or

activity and issue an alert if an attack is underway. Example attack: Denial Of Service attack.

5.11 Server Configuration

All operating systems, network devices, services, and applications shall have the most current security

patches installed.

Servers shall be configured to disallow directory listing and directory traversal attacks.

Servers shall be configured to not unnecessarily disclose information about versions of server software,

installed packages, configured plugins, etc.

Configuration files for servers, applications, and network devices shall not be accessible to

authenticated or unauthenticated users, through the application or other services running on the

system.

File permissions shall be set to limit visibility for all configuration files, and other files that contain

sensitive information.

The web server process shall be run in the context of a non-privileged user.

All unnecessary services shall be disabled on production systems.

All back-end authentication credentials shall be stored encrypted on the servers.

Usernames and passwords shall not be hard-coded.

Third party components shall come from trusted repositories.

All application assets shall be hosted by the application.


Page 14 of 15

5.12 Architecture

Application architecture, network architecture, and data flows shall be documented and provided

Security Group.

All network communications between components shall be authenticated, and shall not explicitly trust

other network devices.

Application server interfaces shall not be accessible from the Internet. This includes DCOM, CORBA,

SOAP, EJB, RPC, and any other method of invoking remote procedure calls.

Application shall not use web sockets until approved by the ANSP. If approved, application shall follow

the security guideline for web sockets.

All network communications between servers shall be encrypted if the servers do not reside on same

physical network segment.

Any administrative functions that are not meant to be accessed by users from the Internet shall be in a

private DMZ, which prevents direct Internet access to the servers.

Systems directly facing the Internet shall not store confidential data.

Internet-facing systems shall not cache confidential data, even for a short duration.

Internet-facing systems shall be placed behind a firewall that protects against network-based denial of

service attacks, blocks ports that are not required for external access, and other network attacks.

Applications shall not connect to a database as a privileged user, such as the SA account in SQL Server

or SYSTEM account in Oracle.

Applications that connect to a database, application server, or any system that utilizes application IDs

shall do so using an account that has been granted access to only objects and functions needed for

operation of the application.

All servers shall be kept in sync with a time synchronization mechanism.

Application shall have a clear separation between the data layer, controller layer and the display layer.

There shall be no sensitive business logic, secret keys or other proprietary information in client side

code.

5.13 Operation

Intrusion detection systems (IDS)/Intrusion Prevention system (IPS) shall be in place to detect

intrusions of production systems that are Internet facing.


Page 15 of 15

Intrusion detection systems (IDS)/ Intrusion Prevention system (IPS) shall be in place to detect

intrusions of production systems that are Intranet facing.

A formal incident response process plan shall be in place for production systems.

Anti-virus software shall be installed and constantly updated on all servers.

Patch management software shall be installed and constantly updated on all servers.

Application server shall have a facility to send logs to syslog server

End of Document

MSB | FW | V0.2 Issue Date: 01/ 2018

Page 1 of 15


FIREWALL

MSB-FW

V0.2


Page 2 of 15


Issue


V0.1 26/11/2017 GCAA – UAE

V0.2 31/01/2018 GCAA-UAE

Reviewers


Approvals


Distribution


Amendments







Page 3 of 15

Table of Contents

1. Introduction ..................................................................................................................... 4

2. References ...................................................................................................................... 4

3. Abbreviations and Acronyms .......................................................................................... 4

4. Change Management.. ................................................................................................... 5

5. Responsibilities and Roles .............................................................................................. 5

6. MSB Directives ............................................................................................................... 5

5.1 Enterprise Wide Standard ...................................................................................................... 5

5.2 Physical Security ................................................................................................................... 6

5.3 Operating System .................................................................................................................. 6

5.4 Backup and Recovery ............................................................................................................ 6

5.5 Password ............................................................................................................................... 7

5.6 Global Firewall Management ................................................................................................. 8

5.7 SNMP .................................................................................................................................... 8

5.8 NTP ....................................................................................................................................... 9

5.9 Threat Detection/Prevention and other Security .................................................................... 9

5.10 Routing and Routing Protocols ............................................................................................ 12

5.11 Logging and Debugging ....................................................................................................... 12

5.12 Authentication, Authorization, and Accounting ..................................................................... 13

5.13 VPN ..................................................................................................................................... 14


Page 4 of 15

1. Introduction

ANSP’s security objectives are to ensure adequate protection of resources, reduction of operating risks

and to maintain the system availability, confidentiality and integrity.

This document defines the standard for ANSP’s during the life cycle process of procurement,

implementation and operation of firewall solutions and other perimeter protection for the ANS Enterprise

Architecture.

ANSP’s shall implement defense-in-depth strategies which enforce a layered security architecture that

provides adequate protection for the ANS Enterprise Architecture.

2. References

ICAO Annex 17

ICAO Doc 9985




3. Abbreviations and Acronyms

AAA Authentication Authorization Accounting SSH Secure Shell

ANS Air Navigation Service CNS Communication Navigation Surveillance

IDS Intrusion Detection System RM Reference Model

MSB Minimum Security Baseline VPN Virtual Private Network

HTTPS Hyper Text Transfer Protocol Secure Dos Denial of Service

UPS Uninterruptible Power Supply OS Operating System

IPS Intrusion Prevention System VTP/DTP Trunking Protocol

RADIUS Remote Authentication Dial-In User Service SNMP Simple Network Management Protocol

LAN Local Area Network ARP Address Resolution Protocol

OSI Open System Interconnection TTY Telety Prewrite

HMAC-MD5 Hashed Message Authentication Code Message Digest 5

VTY Virtual Teletype

UPF Unicast Reverse-Path Forwarding TCP Transmission Control Protocol

NTP Network Timestamp Protocol UDP Used Datagram Protocol

OOB Out of Bound


Page 5 of 15

4. Change Management.


follow a detailed change management process in compliance with the respective regulatory

requirements of that state.



This MSB document shall be reviewed,

Annually,

Depending on the changes incorporated in the environment

6. MSB Directives

The MSB applies to all ANSP offices including the international branches (if any), Inter-department or

Inter-system communication where firewall implementation is required.

This guide does not provide vendor specific firewall security considerations but rather provides a generic

listing of security considerations to be used when implementing a firewall.

This guide ensures adequate protection is in place to protect ANSP’s data from intruders, file tampering,

break in and service disruption to maintain availability, confidentiality and integrity

Following the guidelines shall facilitate administrator to prevent the intrusions and attacks to the best

possible extent. These are the minimum baseline directives to be complied with; for maintaining the

firewall as an effective safeguard.

5.1 Enterprise Wide Standard

Firewalls shall control inbound and outbound network traffic by limiting it to the necessary level required

to accomplish the mission of the Organization.


Page 6 of 15

5.2 Physical Security

The firewall equipment room shall be free of electrostatic or magnetic interference and shall have a

controlled access to only authorized personnel.

Firewall equipment room shall always have:

controls for temperature and humidity,

An uninterruptible power supply (UPS), and

Spare components for contingency purpose.

Firewalls shall not be relocated without the prior approval of the CNS Department

5.3 Operating System

Latest, stable and secure version of the OS and firmware for each firewall shall be installed to mitigate

the susceptible operating system related bugs and vulnerabilities.

It shall be ensured that the installed firmware or software is downloaded from trusted vendor media, or

downloaded from vendor web site. Downloads shall be verified to ensure the integrity. Prior installing

the latest firmware, software or OS release notes shall be reviewed to ensure that, latest version fully

supports the operational needs.

To ensure the successful rollback in case of failure, the device shall have enough memory to keep both

the old and the latest version stored within the device memory. Alternatively, a backup device shall be

in place or device shall operate in high availability mode to perform the upgrade activity offline without

causing a long disruption in network connectivity.

For networks with redundant devices, each redundant device shall be upgraded separately and the

update shall be verified before upgrading the counterpart.

5.4 Backup and Recovery

Up to date backups of configuration and installed software images are important. Network devices’

running-configuration and start-up configuration shall be synchronized. Following steps shall be

adhered:

A backup routine and procedure shall be established.

System reboots or power failure shall not affect the configuration.

Recovery procedures shall be well documented and tested.


Page 7 of 15

5.5 Password

ANSP’s shall follow and abide to their organizational password policy. If there is no such policy

implemented than below steps shall be followed to ensure the adherence of best password practices

Basic encryption shall be enabled to encrypt all the password in device configuration.

Common local username such as admin, netscreen, administrator, cisco, etc. shall never be used

Following guidelines shall be adhered for creating complex password:

o Characteristics of strong and complex passwords shall contain:

o Minimum 12 alphanumeric characters.

o Both upper and lower case letters.

o One number (for example, 0-9).

o One special character (for example, $%^&*() _+|~-=\` {} []:";'<>? /).

o Poor or Weak passwords possess:

o Password length less than eight characters.

o Password that are easily found in a dictionary, including foreign language, or exist in a

language slang, dialect, or jargon.

o Personal information such as birthdates, addresses, phone numbers, or names of family

members, pets, friends, and fantasy characters.

o Work-related information such as building names, system commands, sites, companies,

hardware, or software.

o Number patterns such as aaabbb, qwerty, zyxwvuts, or 123321.

o Familiar words spelled backward, or preceded or followed by a number (for example, terces,

secret1 or 1secret).

o Some well-known examples are “Welcome123” “Password123” “Changeme123”.

System level (admin) passwords should be changed at least once every 90 days.

User level passwords should be changed at least once every 180 days.

Account lockout features such as ‘password retry lockout’ and ‘lockout time’ shall be configured

Passwords stored on network devices shall be encrypted.

Passwords shall not be sent via unencrypted channel over the network.


Page 8 of 15

5.6 Global Firewall Management

All unused interfaces shall be in shut down state

The firewall shall be administered via out-of-band management.

A unique account for each administrator shall be configured to access the console or any other

management console access.

Firewall management console shall not be accessible and hosted over internet.

Same passwords shall not be used for the console line and other services such as SSH, web

management, AUX within the same firewall appliance.

Exec-timeout & SSH timeout duration shall be set to 5 minutes

SSH v2/3 with key size of 2048 bits shall be implemented instead of telnet to remotely manage the

firewall. The access-list shall be implemented to provide remote management access from only

authorized systems.

Devices shall use (local or centralized) AAA server for authentication, authorization & accounting

The SSH authentication retry attempt shall be restricted to 3.

SCP shall only be used for file transfer.

HTTPS web based access shall be used for firewall management and HTTP access shall be

disabled

SSL AES 256 encryption or higher shall be configured for HTTPS.

AUX port access shall be disabled on Firewall. If required, then the modem shall be connected on-

demand basis only.

Access-lists shall be implemented on line interface allowing only required management systems IP

addresses.

All the denied access on management console and other terminal lines shall be logged.

Each firewall policy shall be reviewed and verified at least quarterly.

A legal banner shall be created for the login process within the console line and virtual terminal lines

for each firewall appliances.

5.7 SNMP

SNMP read and write access shall be disabled.

Due to business needs if SNMP is required for the device, then firewall should be configured for

SNMP version 3 with AES128 bit encryption.


Page 9 of 15

SNMP access-list shall be implemented to allow restricted access.

Common SNMP string such as public, private, netcool, admin, administrator, cisco, etc. shall not be

used

For capturing device management alerts, the device shall be configured to submit traps to authorize

management systems only

All the denied access within SNMP access-list shall be logged

5.8 NTP

Device time shall be synchronized with centralized time server

All NTP server should be configured with encrypted authentication keys

UTC time shall be followed

5.9 Threat Detection/Prevention and other Security

Default:

The default firewall policy shall shut all the communication ports. Only those ports for which an

organization has written and documented business need should be open.

ANSP’s shall establish a procedure for firewall configuration change requests which mandates the

strong business case for any firewall change requirement. The respective ANSP’s Information

security office conducts the risk assessment for any firewall change request.

Identity:

Firewall configurations shall be done in such a way that other networks within the environment

cannot identify that this particular firewall is been hosted within a network.

Firewall Rule Set:

Following rule sets shall be configured as minimum:

o Block inbound network traffic from a non-authenticated source system with a destination

address of the firewall system itself.

o Deny all traffic from the external networks that bears a source address belonging to the internal

networks.


Page 10 of 15

o Block inbound network traffic containing ICMP (Internet Control Message Protocol) traffic.

o Block inbound network traffic containing IP Source Routing information.

o Permit Only Required Protocols and Services. Those services that are not explicitly permitted

are prohibited.

o Deny all traffic from the internal networks that bears a source IP address which does not belong

to the internal networks.

o Deny all traffic with a source or destination address belonging to any reserved, unrouteable, or

illegal address range.

o If not required, then block the multicast traffic.

o Block inbound or outbound network traffic containing a source or destination address of 0.0.0.0,

240.0.0.0

o Block inbound or outbound network traffic containing directed broadcast addresses.

o Ensure that there is a rule blocking outgoing time exceeded and unreachable messages.

o Implement an explicit deny entry at the end of each ACL/firewall policy.

o Log all the firewall policies and other important events

Threat Detection/Prevention:

o Known malicious traffic and network address ranges shall be used to block access to malware

sites without having to inspect every packet on the network.

o Firewall shall be configured with auto dynamic update (if applicable) and shall be configured to

use the new database of known malicious sites, viruses and malwares.

o The Botnet Traffic Filter shall be enabled on outside internet facing interface

o DNS snooping shall be configured

o Firewall shall be capable of content filtering and shall have this feature enabled.

o Firewall shall support the Intrusion detection/ Prevention (IDS/IPS) functionality with auto update

capability of updating necessary signatures

o Logout timers shall be set so that the device closes connections after they become idle.

o Device shall be configured to prevent fragmented packets on external or high risk interfaces.

o Traffic inspection shall be enabled for commonly attacked protocols.

o Unwanted services shall be disabled.

o Loose source routing and strict source routing shall be blocked and shall be logged by the

firewall.

o The ACK bit monitoring shall be enabled (if applicable) to ensure that a remote system cannot

initiate a TCP connection, but can only respond to packets sent to it.

o Unicast reverse-path forwarding (RPF) shall be enabled on all interfaces.

o DOS protection shall be enabled on all interfaces.

o Threat detection statistics should be enabled for attacks blocked by the TCP Intercept function.

Network Address Translation (NAT):


Page 11 of 15

o Network address translation (NAT) shall be configured to prevent direct access from the internet

to user and non-publicly available infrastructure devices.

o Users shall access the internet through NAT to hide internal topology and prevent direct access

from the internet.

o The random sequence number shall be enforced for Static NAT.

Others:

o Device shall utilize object groups to simplify security policy rules.

o Failover Key shall be enforced as per the ANSP’s password requirements.

o DNS services shall be disabled if not required. If required, DNS service shall be configured

properly for DNS queries.

o DHCP, SNMP, Web management service shall be disabled or restricted to the necessary

systems.

o The firewall shall be properly configured to know which hosts are on which interface.

o The firewall access control lists and policies shall be reviewed periodically to ensure that the

appropriate traffic is routed to the appropriate segments.

o If the firewall is state full, the packet filtering for UDP/TCP 53 shall be enabled. IP packets for

UDP 53 from the Internet shall be limited to authorized replies from the internal network. If no

reply to a request from the internal DNS server, the firewall shall deny it. The firewall shall also

deny IP packets for TCP 53 on the internal DNS server, besides those from authorized external

secondary DNS servers, to prevent unauthorized zone transfers.

o Firewalls operate on a first match basis; thus, the structure is important to ensure that suspicious

traffic is kept out instead of inadvertently allowing them in by not following the proper order.

Following order shall be adhered while implementing the rule sets:

anti-spoofing filters (blocked private addresses, internal addresses appearing from the

outside) in Firewall Rule Set

User permit rules (e.g. allow HTTP to public web server)

Management permit rules (e.g. SNMP traps to network management server)

Noise drops (e.g. discard OSPF and HSRP chatter)

Deny and Alert (alert systems administrator about traffic that is suspicious)

Deny and log (log remaining traffic for analysis)

o Only the secure protocols traffic which includes HTTPS, SSH, SFTP, VPN, SMTP over TLS

shall be allowed through external firewall to internet host.

o Unsecure protocols which include but not limited to FTP, Telnet, POP3, IMAP, and SNMP shall

not be allowed through Firewall from external system (unless approved by CNS)

o All the access which allow access from internal host to internet system and vice versa shall be

documented


Page 12 of 15

o The firewall rule sets shall be reviewed quarterly.

o The protocol inspection security feature shall be enabled for all the protocols for which traffic is

allowed to pass through the firewall.

o The DMZ shall be implemented to limit the services from the internet hosts to authorized publicly

accessible systems; allowed services shall be limited to HTTPs, SMTP, VPN and SFTP. Prior

approval is required from CNS for any other services.

o The direct access from internet host to internal host shall never be allowed without the DMZ

enforcement.

o The DMZ server access shall be limited to only authorized web sites

o System which store business sensitive data shall be installed in dedicated firewall zone having

strict access rules being implemented.

5.10 Routing and Routing Protocols

All unused routing protocols shall be disabled and no configuration shall exist for unused protocols.

A specific neighbour device’s source IP address shall only be permitted in access-list for routing

protocol traffic.

The neighbouring device authentication should be enabled to protect the integrity of a routing

domain.

Distribute the neighbouring device authentication key manually.

Message Authentication Code Message Digest 5 (MD5) Authentication should be enabled for BGP,

OSPF, EIGRP & RIP v-2.

Hashed Message Authentication Code Message Digest 5 (HMAC-MD5) Authentications should be

enabled for IS-IS.

The route learning of unused interface shall be disabled

The necessary route filtering mechanism shall be implemented to protect the routing table coverage.

Black-Hole Routing shall be used for blocked traffic.

Unicast Reverse-Path Forwarding (UPF) Verification shall be enabled.

Proxy ARP shall be disabled on all interfaces.

5.11 Logging and Debugging

Syslog messages shall be forwarded to a centralized server.

Ensure that the syslog server has adequate storage and processing capacity.

Enable detailed logging for critical systems or on systems exposed to external users


Page 13 of 15

Enable the syslog organized output on syslog server by using facility numbers. Enable information

level’s Syslog trap on all firewalls

Define the source IP address to be used for syslog messages. This will typically be a loopback or

an OOB interface to ensure consistency.

Ensure timestamps are enabled as per the guidelines in the section Timestamps and NTP

Ensure syslog messages are stored in a searchable database

The syslog server shall be hardened and cryptographic techniques to be considered for log

protection

Enable the Syslog facility to direct logs from each firewall to at least one log host, which shall be a

dedicated system on the protected network. Typically, the log host has a Syslog service enabled to

receive logs. On the log host disable all unnecessary TCP or UDP services. Also, remove all

unnecessary user accounts.

Enable the sequence reference number for each of the Syslog generated by firewall device

The buffered logging shall be enabled for notification logs and the buffer log size shall be set to at

least 16000.

Events indicating performance problems and functional failures shall be recorded.

All changes to configuration shall be logged.

Logging features on network firewalls shall capture all packets dropped or denied by the firewall,

and information security team shall review those logs at least monthly.

5.12 Authentication, Authorization, and Accounting

Implement the centralized RADIUS server for authentication, authorization & accounting instead of

creating the local user account for device administrator via Console, terminal line (VTY, TTY), AUX,

PPP & Enable mode access.

Implement multiple AAA servers for redundancy.

Bind the authentication, authorization and accounting (AAA) services to the loopback interface.

Users should integrate with the system wide AAA

Users shall be assigned individual user accounts

User accounts shall be assigned with minimal privileges, and only in accordance with operational

needs.

The number of privilege users shall be restricted

Active users shall re-authenticate themselves after a period of idle-time.


Page 14 of 15

Create one local user account with privilege level 1 for emergency access in case of AAA server is

not reachable. Local user shall not be configured with more than privilege level 1.

Periodically review the administration and device command logs activity on AAA server.

Re-authentication of devices and users shall occur for proper intervals.

5.13 VPN

The Site to Site VPN shall be restricted through interface access-list and shall only allow the remote

site IP to connect via IPSec.

Following shall be but not limited to ISAKMP Policy for Site to Site VPN

o Authentication: pre-share or security certificates

o encryption: AES-256/512 or greater

o hash SHA-512 or greater

o DH group: 5 or greater

o Lifetime: 86400

Following shall be but not limited to the IPSec Policy for Site to Site VPN.

o Mode: ESP

o Encryption: AES-256 or greater

o Hash SHA-256 or greater

The pre-shared key password shall be at least 15 characters long; not based on words; and include

at least one character from each of the sets of letters, numbers and special characters (e.g., /<>;':"[]

\ {} |~! @#$%^&*()_+`-= )

VPN Access-list shall include the necessary permission and host/port level permission further

filtered on interface access-list.

The access control system should be used to dynamically enforce user based access-list instead of

defining static access-list on firewall.

Two-factor authentication should be used for remote-access VPN authentication.

A trusted and valid certificate shall be used to verify the Identity of an SSL termination point.

Latest and robust VPN client shall be deployed on machines.

An idle timeout for SSL VPN sessions shall be configured.

Local password caching shall be disabled

Main mode should be configured for VPN


Page 15 of 15

End of Document

MSB | LINUX | V0.2 Page 1 of 10 Issue Date: 01/ 2018


LINUX OS, SYSTEMS and SERVERS

MSB-LINUX

V0.2


Document Control

Signing in the respective section below confirms that you have read the document fully and approve its contents.

Issue


V0.1 26/11/2017 GCAA – UAE

V0.2 31/01/2018 GCAA – UAE

Reviewers


Approvals


Distribution


Amendments







Table of Contents

1. Introduction ..................................................................................................................... 4

2. References ..................................................................................................................... 4



5. MSB Directives ............................................................................................................... 5

5.1 Basic Security ........................................................................................................................... 6

5.2 Operating system & Services Security ..................................................................................... 6


1. Introduction

ANSP’s shall develop security techniques, practices and tools to reduce the risks associated with inter-

connectivity and usage of various ANSP networks. One of the basic security objectives is to ensure the

proper protection of the resources, reduction of operating risks and to increase the system availability,

confidentiality and integrity.

This baseline provides technical recommendations intended to help LINUX System administrators improve

the security of ANSP networks. In reference to the recommendations mentioned in this document, LINUX

administrators shall configure the LINUX systems to control access, resist attacks, shield other resources

and protect the integrity and confidentiality of the system data.

2. References

ICAO Annex 17

ICAO Doc 9985





ANS Air Navigation Services

CDE Common Desktop Environment

CNS Communication Navigation Surveillance

DHCP Dynamic Host Configuration Protocol

FTP File Transfer Protocol

ICMP Internet Control Message Protocol

IPV6 Internet Protocol Version 6


NFS Network File System

SCP Secure Copy

SMRUF Type of Denial of service attack


SNMP Simple Network Management Protocol

SSH2 Secure Shell version 2

SU Super User

SYN Synchronous Flag

TCP Transmission Control Protocol

TFTP Trivial File Transfer Protocol

UID User ID

XDMCP Remote Desktop Protocol




of that state



This document shall be reviewed

Annually,

Depending on changes incorporated in the environment.

6. MSB Directives

This document is intended to guide ANSP to prevent unauthorized access to the network through the

establishment of basic requirements for Linux operating systems and server configurations.

Below steps should assure the secure LINUX assets secure environment and would assist ANSP’s to

prevent external intrusions to the best possible extent.

The following guidelines to be considered prior to implementing the standard:

Ensure that the system is functioning properly before a change is made.


Backup critical configuration files as well as system data.

The actions in this document are written with the assumption that the execution will be done by the root

user running the shell and without noclobber set. Also, the following directories are assumed to be in root's

path:

/usr/bin:/etc:/usr/sbin:/usr/ucb:/sbin

5.1 Basic Security

All the unused software & services shall be removed (e.g. ftp telnet shell login exec

echo discard chargen daytime time ttdbserver dtspc ntalk rstatd rusersd rwalld sprayd pcnfsd cmsd)

The operating system shall be updated regularly. The update patches shall be downloaded from verified

vender sites and the integrity of such software/patches shall be verified using file or package signatures

(if provided) or at least MD5 checksums. Always ensure that an operating system patch shall not re-

enable a service which was disabled.

The system shall use Network Time Protocol (NTP). It shall synchronize the system clock with reliable

centralized clocks.

The use of removable media on operational equipment shall be kept to a minimum and where possible USB access shall be disabled.

Auto mount shall be disabled on the systems where use of removable media is required. Mounting of devices shall be carried by non-admin user/group with the help of sudo utility to make sure the privileges of any unwanted process is limited to the logged user profile.

When using removable media such as a memory stick/external drive etc. it shall be scanned for viruses and be completely file free before use. A virus scan shall be carried out even if there are no visible files on the memory stick, due to hidden virus/malware files. If possible, encrypted USB media should be used.

5.2 Operating system & Services Security

SSHv2 shall only be allowed. This can be set in /etc/ssh/sshd_config.

“sudo” shall be implemented and only authorized users shall be defined in the /etc/sudoers file,

including specific command.

ASLR (Address Space Layout Randomization) and DEP (Data Execution Prevention) shall be enabled

Compiler tools shall be removed from production systems.

“/home” folder should be mounted from different partition.


Latest version of TCP wrappers package shall be installed and TCP wrappers shall be configured to

limit the access to authorized systems.

Set default locking screensaver timeout to 10 minutes in CDE session manager.

Root logins shall be restricted to system console.

Administrative accounts shall only be allowed to use the su command. Monitor the su command’s logs

in the log folder.

ANSP’s shall follow and abide to their organizational password policy. If there is no such policy

implemented then the following user password policy shall be implemented to ensure the adherence of

best password practices

Password Policy

Password Expiration Should be 90 days

Password History Shall be 3

Minimum Length Shall be 8 characters

Password Complexity Passwords shall be alphanumeric, and include at least one

lowercase and one uppercase letter, one number and one

special character

System shall integrate with centralized LDAP/RADIUS for authentication.

Expiring feature of idle accounts should be enabled.

Periodic checks shall be conducted to verify there are no accounts with empty password fields.

Failed login attempts shall be limited to 5.

Periodic checks shall be conducted to verify no UID 0 accounts exist other than root.

All unnecessary default user accounts shall be removed

rlogin/rsh/rcp services shall be disabled. ssh/scp shall be used

TFTP Server shall only be enabled if required.

Kerberos-related daemons shall only be enabled if necessary.

Rquotad service shall be disabled


CDE-related daemons shall only be enabled if required

Login prompts on serial ports shall be disabled. By disabling the getty process on the system serial

ports, it is made more difficult for unauthorized users to attach modems, terminals, and other remote

access devices to those ports.

Inetd shall be disabled.

Email server shall be disabled on all the machines except Email Gateway server. Email server is

required on machines that act as mail servers, receiving and processing email from other hosts on the

network.

NIS (Network Information Service) Server & Client processes shall be disabled

NFS Server processes shall be disabled if not required. If the machine is an NFS server, the NFS

access shall be restricted by IP addresses, exporting file systems “read-only” and “nosuid” where

appropriate.

NFS Client processes shall be disabled if not in use and NFS client software packages shall be

removed. If in use, NFS client requests shall be restricted to privileged ports.

GUI login shall be disabled if not required.

Printer daemons shall only be enabled if required.

SNMP shall only be enabled on the machines required for monitoring. When SNMP is enabled, the

community string shall be changed from default value. In addition, the address/netmask and permissions

parameters shall be used on the community statement to restrict SNMP access to management stations.

Port map shall only be enabled if required.

IPv6 protocol shall be disabled if not in use

IP Source Routing shall be disabled (net.ipv4.conf.all.accept_source_route = 0 or

net.ipv6.conf.all.accept_source_route = 0)

DHCP shall be disabled unless it is required for operational use. CNS approval is required for enabling

the DHCP service

writesrv, pmd, httpdlite commands shall only be enabled if required.

Core dumps should be disabled to prevent the storage of sensitive information in dump file.

TCP SYN Cookie Protection shall be enabled (edit the sysctl.conf {net.ipv4.tcp_syncookies = 1})

SMURF broadcast attacks and other broadcast traffic shall not be allowed

ICMP Redirect Acceptance shall be disabled (in /sysctl.conf {net.ipv4.conf.all.accept_redirects = 0 or

net.ipv6.conf.all.accept_redirects = 0})


IP Spoofing Protection shall be enabled (net.ipv4.conf.all.rp_filter = 1)

Reverse Path Filtering shall be enabled

Source-routed packets shall not be processed by default.

All log entries shall be logged with UTC Time Stamp

All errors, exceptions, and other error conditions shall be logged and shall only be visible to super user.

All type of security logging shall be enabled such as valid and failed login attempts and shall be visible

only to super user. Passwords shall not be logged.

The authorization events logging shall be enabled and shall only be visible to super user.

Kernel-level auditing shall be enabled.

Other critical events such as network connectivity problems, performance issues, hardware failures and

related systems startup and shutdown shall be logged.

System’s Bash shall be compiled (patched) with syslog facility.

Important event logs and messages shall be sent to syslog, especially the AUTH facility.

sar accounting shall be enabled to gather baseline system data (CPU utilization, disk I/O, etc.).

The log files shall be protected from manipulations by unauthorized individuals. Certain logs contain

sensitive data that shall be available to the system administrator, therefore the permission of log files

shall be reviewed periodically.

The passwd and group file permissions shall be reviewed periodically.

World-writable directories shall have their sticky bit set.

It shall be periodically checked that no rogue set-UID programs have been introduced into the system.

A system health checks shall be conducted on regular basis to find ‘unowned’ files and directories and

to verify their existence.

/etc/hosts.equiv file shall be removed if not used.

XDMCP port shall be disabled.

Server shall be prevented from listening on port 6000/tcp.

Empty crontab files shall be removed and file permissions shall be restricted to authorized users.

No legacy '+' entries shall exist in passwd, and group files.

No '.' or group/world-writable directory shall exist in root's $PATH.

User home directories shall be mode 750 or more restrictive.


No user dot-files shall be world-writable.

User. netrc and .rhosts files shall be removed

Default umask for users shall be set to 077.

Warning banners shall be implemented for GUI-based logins, telnet, network and physical access

services.

The default /etc/motd message shall be changed to include a legal message stating that the server is

a private system and property of the respective ANSP.

Warnings banner for FTP daemon (if enabled) shall be changed to "ANSP authorized users only"

banner messages by replacing the default “FTP server ready” message.

System shall have some type of Antivirus and Antimalware to enhance the protection against new

attacks

Auto mount shall be disabled for all the accounts

System shall not allow the mounting of any device for all type of user accounts except super user.

End of Document

MSB | ROUTER | V0.2 Issue Date: 01/ 2018

Page 1 of 15


ROUTER

MSB-ROUTER

V0.2


Page 2 of 15


Issue


V0.1 26/11/2017 GCAA – UAE

V0.2 31/01/2018 GCAA-UAE

Reviewers


Approvals


Distribution


Amendments







Page 3 of 15

Table of Contents

1. Introduction ..................................................................................................................... 4

2. References ..................................................................................................................... 4


4. Change Management ..................................................................................................... 6


6. MSB Directives ............................................................................................................... 6

5.1 Physical Security ...................................................................................................................... 6

5.2 Operating System ..................................................................................................................... 7

5.3 Backup and Recovery ............................................................................................................... 7

5.4 Password .................................................................................................................................. 8

5.5 Router Management & Monitoring ............................................................................................ 9

5.6 SNMP ........................................................................................................................................ 9

5.7 NTP ......................................................................................................................................... 10

5.8 Traffic Filtering ........................................................................................................................ 10

5.9 Network Services ......................................................................................................................... 11

5.10 Routing and Routing Protocols ............................................................................................... 12

5.11 Authentication, Authorization, and Accounting ....................................................................... 13

5.12 Logging and Debugging .......................................................................................................... 13

5.13 VPN ......................................................................................................................................... 14

5.14 WAN Links .............................................................................................................................. 14

5.15 System Availability .................................................................................................................. 15


Page 4 of 15

1. Introduction

ANSP’s security objectives are to ensure adequate protection of resources, reduction of operating risks and

to maintain the system availability, confidentiality and integrity.

This document defines the standard for ANSP during the life cycle process of procurement, implementation

and operation of routing solutions and other perimeter protection for their Enterprise Architecture.

ANSP’s shall implement a defense-in-depth strategy which enforces a layered security architecture that

provides adequate protection for their Enterprise Architecture.

Routing solutions are responsible for defining data packets across computer networks. This documents

provides technical guidelines intended to help network administrators improve the security of their ANSP

networks.

Following the information provided, a network administrator can configure routers to control access, resist

attacks, shield other network systems and safeguard the ANSP network traffic.

2. References

ICAO Annex 17

ICAO Doc 9985





AAA Authentication Authorization Accounting

ANS Air Navigation Service

ARP Address Resolution Protocol


Page 5 of 15

CDP CISCO Discovery Protocol


DoS Denial of Service

FTP / SFTP File Transfer Protocol / Secure FTP

HTTPS Hyper Text Transfer Protocol Secure

LAN Local Area Network

MOP Maintenance Operations Protocol


OSI Open System Interconnection

OS Operating System

PAD Packet Assembler/Dis-assembler

POP3/IMAP Mailing Protocols

QoS Quality of Service

RADIUS Remote Authentication Dial-In User Service

RM Reference Model

SMTP Simple Mail Transfer Protocol


SSH Secure Shell

UDLD Unidirectional Link Detection

UPS Uninterruptible Power Supply

VLAN Virtual LAN VPN Virtual Private Network


Page 6 of 15




of that state


CNS Department is responsible for implementing and maintaining the MSB defined in this document. This

MSB document shall be reviewed,

Annually,


6. MSB Directives

The MSB applies to all ANSP offices including the international branches (if any), Inter-department or Inter-

system communication where router implementation is required.

This guide does not provide vendor specific router security considerations but rather provides a generic

listing of security considerations to be used when implementing a router.

This guide ensures adequate protection is in place to protect ANSP data from intruders, file tampering,


Following the guidelines shall facilitate administrator to prevent the intrusions and attacks to the best

possible extent. These are the minimum baseline directives to be complied with; for maintaining the router

as an effective safeguard.


The router equipment room shall be free of electrostatic or magnetic interference and shall have a controlled

access to only authorized personnel.

Router equipment room shall always have:


Page 7 of 15



Spare components for contingency purpose.


Latest, stable and secure version of the OS and firmware for each router shall be installed to mitigate the

susceptible operating system related bugs and vulnerabilities.


downloaded from vendor web site. Downloads shall be verified to ensure the integrity. Prior installing the

latest firmware, software or OS release notes shall be reviewed to ensure that, latest version fully supports

the operational needs.

To ensure the successful rollback in case of failure, the device shall have enough memory to keep both the

old and the latest version stored within the device memory. Alternatively, a backup device shall be in place

or device shall operate in high availability mode to perform the upgrade activity offline without causing a

long disruption in network connectivity.

For networks with redundant devices, each redundant device shall be upgraded separately and the update

shall be verified before upgrading the counterpart.


Up to date backups of configuration and installed software images are important. Network devices’ running-

configuration and start-up configuration shall be synchronized. Following steps shall be adhered:





Page 8 of 15

5.4 Password

ANSP’s shall follow and abide to their organizational password policy. If there is no such policy implemented

than below steps shall be followed to ensure the adherence of best password practices









o Weak or poor passwords possess:


o Password that are easily found in a dictionary, including foreign language, or exist in a language

slang, dialect, or jargon.















Page 9 of 15

5.5 Router Management & Monitoring

The Password encryption service shall be enabled globally on router.

Router shall be administered via out-of-band management. A unique account shall be made for each

administrator to access the console line.

Same passwords shall not be used for the console line and for other services such as telnet, AUX within

the same router appliance.

The “enable Secret” option shall be activated instead of ‘enable” password to enforce the encryption.



router. The access-list shall be implemented to provide remote management access from only

authorized systems.



Web based access should be disabled. If it is required, HTTPS web based access shall only be enabled

AUX port access shall be disabled on router. If required, then the modem shall be connected only on-

demand basis.


addresses.

Log all the denied access by line interface access-list.

Creation of unnecessary loopback and tunnel interfaces shall be restricted

A legal banner for the login process into the console line & Virtual terminal lines shall be created for

each Router.

5.6 SNMP



Page 10 of 15

Due to business needs if SNMP is required for the device, then router should be configured for SNMP

version 3 with AES128 bit encryption.



used




5.7 NTP




5.8 Traffic Filtering

Required protocols and services shall be enabled and services that are not explicitly permitted shall be

prohibited.

Traffic from the internal networks that bears a source IP address which does not belong to the internal

networks shall be restricted or blocked

Traffic from the external networks that bears a source address belonging to the internal networks shall

be restricted or blocked

Traffic with a source or destination address belonging to any reserved, unrouteable, or illegal address

range shall be restricted or blocked

Packet destined to any broadcast address shall be denied.

Packets containing IP options shall be dropped by ACLs.

Multicast traffic shall be disabled if not required for operational use

Inbound traceroute shall be disabled.


Page 11 of 15

Enable turbo access lists on a router.

Only the secure protocols traffic which includes Https, SSH, SFTP, VPN, SMTP over TLS shall be

allowed through external Router to internet host.

Unsecure protocol which include but not limited to FTP, Telnet, POP3, IMAP, and SNMP shall not be

allowed through External Router.

Filtering shall be applied to protect the device from unauthorized access

Provisioning of unsecure protocol through router is subject to valid business requirement and CNS

Head approval.

All the entries which allows access from internal host to internet system and vice versa shall be logged

Review of router rule sets shall be conducted quarterly

Enable the protocol inspection security feature for all the protocols

If the router is using the ISP network, then implement the IPSec for this communication and allow the

necessary traffic over IPSec tunnel.

The firewall & Intrusion detection/ prevention (IDS/IPS) functionality on router shall be enabled provided

it is supported by the platform and OS.

If IPS/IDS is enabled, the necessary signature fields shall be enabled to ensure execution of proper

action for well-known attacks and IDS/IPS signature shall be updated periodically.

5.9 Network Services

Following configuration shall be implemented

Disable each unnecessary network service on router

Disable BOOTP services

Disable finger services

Disable DHCP services

Disable identification (identd) server services.

Disable the Configuration Autoload feature other than the local storage devices of router

Disable the Packet Assembler/Dis-assembler (PAD) Services

Disable the Address Resolution Protocol (ARP) Service if not used


Page 12 of 15

Disable host unreachable, redirect and mask reply types of ICMP messages

Disable Directed broadcasts

Disable DNS server’s name resolution query feature

Disable the SNMP service

Disable the cisco discovery protocol (CDP) for a cisco router

Disable IP Source routing.

Disable IP directed broadcast.

Disable the Maintenance Operations Protocol (MOP).

Disable remote start-up configuration.

Disable trivial file transfer protocol (TFTP) server service.

Enable the TCP keepalives-out & keepalives-In services are enabled.

Verify proxy ARP is disabled on all interfaces.

Verify no tunnel or loopback interfaces are created without any strong technical reason.


All unused routing protocols shall be disabled and no configuration shall exist for unused protocols.


protocol traffic.

The neighbouring device authentication should be enabled to protect the integrity of a routing domain.

Distribute the neighbouring device authentication key manually.

Message Authentication Code Message Digest 5 (MD5) Authentication should be enabled for BGP,

OSPF, EIGRP & RIP v-2.


enabled for IS-IS.

The route learning of unused interface shall be disabled




Page 13 of 15



Critical services shall be defined and prioritized using QOS.

Traffic shall be prioritized and policed as close to the end-point as possible and implemented throughout

the network with common policy settings

5.11 Authentication, Authorization, and Accounting





The authentication, authorization and accounting (AAA) services shall be bound to the loopback

interface.

Users shall integrate with the system wide AAA


User accounts shall be assigned minimal privileges, and only in accordance with operational needs.



A local user account shall be created with privilege level 1 for emergency access in case of AAA server

unavailability. Local user shall not be configured with more than privilege level 1.

Periodically review the administration and router command logs activity on AAA server.







Page 14 of 15


level’s Syslog trap on all routers

Define the source IP address to be used for syslog messages. This will typically be a loopback or an

OOB interface to ensure consistency.



The syslog server shall be hardened and cryptographic techniques to be considered for log protection

Enable the Syslog facility to direct logs from each router to at least one log host, which shall be a




Enable the sequence reference number for each of the Syslog generated by router device

The buffered logging shall be enabled for notification logs and the buffer log size shall be set to at least

16000.



Logging features on ANSP network routers shall capture all packets dropped or denied by the router,


5.13 VPN

Router as a VPN Gateway for remote access or SSL VPN shall not be used.

VPN service shall not be used on Perimeter Router.

5.14 WAN Links

The respective CNS Head’s approval is required for the deployment of new WAN link or any of the

design changes related to present WAN links which are connecting to Third parties, ANSP Partners

and International locations.

VPN should be implemented on all the links between ANSP and stakeholders.


Page 15 of 15

5.15 System Availability

Assure that even the lowest priority processes get some processor time in event of flooding attack.

Flow Control shall be turned off on each interface.

Unidirectional Link Detection (UDLD) shall be disabled globally and on every interface where it is not

required.

To help prevent the SYN Flood attack, the reasonable amount of time shall be set, for which the router

will wait while attempting to establish a TCP connection.

Quality of Services shall be enabled for Voice traffic.

To help protect against DoS Attacks, and to allow it to support the widest range of security services,

the router shall be configured with the maximum amount of memory possible.

End of Document

MSB | SW | V0.2 Issue Date: 01/ 2018

Page 1 of 17


SWITCH

MSB-SW

V0.2


Page 2 of 17


Issue


V1.0 26/11/2017 GCAA – UAE

V0.2 31/01/2018 GCAA-UAE

Reviewers


Approvals


Distribution


Amendments







Page 3 of 17

Table of Contents

1. Introduction ..................................................................................................................... 4

2. References ..................................................................................................................... 4

3. Abbreviations and Acronyms AAA Authentication Authorization Accounting ................. 4

4. Change Management ..................................................................................................... 5


6. MSB Directives ............................................................................................................... 6

5.1 Physical Security ...................................................................................................................... 6

5.2 Switch Design ........................................................................................................................... 6

5.3 Operating System ..................................................................................................................... 8

5.4 Backup and Recovery ............................................................................................................... 8

5.5 Password .................................................................................................................................. 9

5.6 Global Switch Management .................................................................................................... 10

5.7 SNMP ...................................................................................................................................... 11

5.8 NTP ......................................................................................................................................... 11

5.9 Network Services .................................................................................................................... 11

5.10 Port Security ........................................................................................................................... 12

5.11 Virtual Local Area Network ..................................................................................................... 13

5.12 Virtual Trunking Protocol (VTP) .............................................................................................. 13

5.13 Trunk Configuration ................................................................................................................ 13

5.14 System Availability .................................................................................................................. 14

5.15 Spanning Tree Protocol .......................................................................................................... 14

5.16 Routing and Routing Protocols ............................................................................................... 14

5.17 Logging and Debugging .......................................................................................................... 15

5.18 Authentication, Authorization and Accounting ........................................................................ 16


Page 4 of 17

1. Introduction

ANSP’s security objectives are to ensure adequate protection of resources, reduction of operating risks and

to maintain the system availability, confidentiality and integrity.

This document defines the standard for ANSP’s during the life cycle process of procurement,

implementation and operation of switching solutions and other perimeter protection for the ANS Enterprise

Architecture.

ANSP’s shall implement defense-in-depth strategies which enforce a layered security architecture that

provides adequate protection for the ANS Enterprise Architecture.

Switching solutions are responsible for defining data packets across computer networks. This document

provides technical guideline intended to help network administrators improve the security of the ANSP’s

networks.

Following the information provided, a network administrator can configure switches to control access, resist

attacks, shield other network systems and safeguard the ANSP’s network traffic.

2. References

ICAO Annex 17

ICAO Doc 9985





AAA Authentication Authorization Accounting

ANS Air Navigation Service

ARP Address Resolution Protocol

CDP CISCO Discovery Protocol


COS Class of service

DoS Denial of Service


Page 5 of 17

DTP Dynamic Trunking Protocol

FTP / SFTP File Transfer Protocol / Secure FTP


LAN Local Area Network

MOP Maintenance Operations Protocol


OS Operating System

OSI Open System Interconnection

PAD Packet Assembler/Dis-assembler

POP3/IMAP Mailing Protocols

QoS Quality of Service

RADIUS Remote Authentication Dial-In User Service

RM Reference Model

SMTP Simple Mail Transfer Protocol


SSH Secure Shell

UDLD Unidirectional Link Detection

UPF Unicast Reverse-Path Forwarding

UPS Uninterruptible Power Supply

VLAN Virtual LAN

VPN Virtual Private Network

VTP Virtual Trunking Protocol




of that state




Annually,



Page 6 of 17

6. MSB Directives

The MSB applies to all ANSP offices including the international branches (if any), Inter-department or Inter-

system communication where switch implementation is required.

This guide does not provide vendor specific switch security considerations but rather provides a generic

listing of security considerations to be used when implementing a switch.

This guide ensures adequate protection is in place to protect ANSP’s data from intruders, file tampering,


Following the guideline shall facilitate administrator to prevent the intrusions and attacks to the best possible

extent. These are the minimum baseline directives to be complied with; for maintaining the switch as an

effective safeguard.


The switch equipment room shall be free of electrostatic or magnetic interference and shall have a

controlled access to only authorized personnel.

Switch equipment room shall always have:



Spare components for contingency purpose

5.2 Switch Design

In a well-formed hierarchical network, there are three defined layers: access, distribution and core. In an

enterprise network, each layer provides distinct functions. These layers are not always recognized by their

traditional names and have been referred to as access or workgroup, distribution or policy, and core or

backbone respectively.

The access or workgroup layer connects end devices such as PCs, printers, IP video surveillance cameras

etc. It is the place where IT managed devices are deployed that extend the network further out one more


Page 7 of 17

level, such as IP phones and wireless access points connecting wired or wireless end users. At the access

layer, following configuration shall be carried

MAC address filtering should be enabled to ensure only certain systems can access the connected

LANs.

Separate collision domains (VLANs) shall be created to segregate the networks for improving

performance.

Load Balancing should be enabled to optimize the handling of switch bandwidth:

Local area network (LAN) switches exist most commonly in the access layer.

The distribution/ workgroup layer/ aggregation layer/ policy layer is the network demarcation boundary

between the Layer 2 wiring closet network and the Layer 3 routed core network. It also provides policy-

based network connectivity, including:

Packet filtering (firewalling): Processes packets and regulates the transmission of packets based

on its source and destination information to create network borders.

QoS: The layer 3 switches can read packets and prioritize delivery, based on policies set.

Access Layer Aggregation Point: The layer serves the aggregation point for the desktop layer

switches.

Control Broadcast and Multicast: The layer serves as the boundary for broadcast and multicast

domains.

Application Gateways: The layer allows to create protocol gateways to and from different network

architectures.

The distribution layer also performs queuing and provides packet manipulation of the network

traffic.

The core layer is responsible for fast and reliable transportation of data across a network. The core layer is

often known as the backbone or foundation network because all other layers rely upon it. Its purpose is to

reduce the latency time in the delivery of packets. The factors to be considered while designing devices to

be used in the core layer are:

High data transfer rate: Speed is important at the core layer. One way that core networks enable

high data transfer rates is through load sharing, where traffic can travel through multiple network

connections.

Low latency period: The core layer typically uses high-speed low latency circuits which only

forward packets and do not enforce policies.


Page 8 of 17

High reliability: Multiple data paths ensure high network fault tolerance; if one path experiences a

problem, then the device can quickly discover a new route.

At the core layer, efficiency is the key term. Fewer and faster systems create a more efficient backbone. It

does not get involved in extensive packet manipulation. The central servers might also be attached to the

high-speed backbone in the core. Standard Switches, high-speed Switches and occasionally LAN Switches

can be found in the core layer.

Above explained the three-layered recommended network architecture; however, there are several other

architectures that are possible.


Latest, stable and secure version of the OS and firmware for each switch shall be installed to mitigate the

susceptible operating system related bugs and vulnerabilities.


downloaded from vendor web site. Downloads shall be verified to ensure the integrity. Prior installing the

latest firmware, software or OS release notes shall be reviewed to ensure that, latest version fully supports

the operational needs.

To ensure the successful rollback in case of failure, the device shall have enough memory to keep both the

old and the latest version stored within the device memory. Alternatively, a backup device shall be in place

or device shall operate in high availability mode to perform the upgrade activity offline without causing a

long disruption in network connectivity.

For networks with redundant devices, each redundant device shall be upgraded separately and the update

shall be verified before upgrading the counterpart.


Up to date backups of configuration and installed software images are important. Network devices’ running-

configuration and start-up configuration shall be synchronized. Following steps shall be adhered:



Page 9 of 17



5.5 Password

ANSP’s shall follow and abide to their organizational password policy. If there is no such policy implemented

than below steps shall be followed to ensure the adherence of best password practices









o Weak passwords possess:


o Password that are easily found in a dictionary, including foreign language, or exist in a language

slang, dialect, or jargon.











Page 10 of 17





5.6 Global Switch Management

Devices should be configured with appropriate naming conventions.

Password encryption service shall be enabled globally on Switch.

Switch shall be administered via out-of-band management.

A unique account for each administrator shall be configured to access the console or any other

management console access.

Same passwords shall not be used for the console line and other services such as SSH, web

management, AUX within the same switch appliance.

The “enable Secret” feature shall be activated instead of ‘enable” password to enforce the encryption.



switch. The access-list shall be implemented to provide remote management access from only

authorized systems.



All the management protocol except the SSH shall be disabled on Line interface.

Web based access should be disabled. If it is required, HTTPS web based access shall only be enabled

AUX port access shall be disabled on switch. If required, then the modem shall be connected on-

demand basis only.


addresses.

Log all the denied access by line interface access-list.


Page 11 of 17

Unnecessary loopback and tunnel interfaces shall not be created

A legal banner for the login process into the console line & Virtual terminal lines shall be created for

each Switch.

5.7 SNMP


Due to business needs if SNMP is required for the device, then switch should be configured for SNMP

version 3 with AES128 bit encryption.



used




5.8 NTP




5.9 Network Services

Following configuration shall be implemented

Disable Unnecessary network service

Disable BOOTP services

Disable finger services

Disable DHCP services


Page 12 of 17

Disable identification (identd) server services.

Disable the Configuration Autoload feature other than the local storage devices of switch

Disable the Packet Assembler/Dis-assembler (PAD) Services

Disable the Address Resolution Protocol (ARP) Service if not used

Disable host unreachable, redirect and mask reply types of ICMP messages

Disable Directed broadcasts

Disable DNS server’s name resolution query feature

Disable the SNMP service

Disable the cisco discovery protocol (CDP) for a cisco switch

Disable IP Source routing.

Disable IP directed broadcast.

Disable the Maintenance Operations Protocol (MOP).

Disable remote start-up configuration.

Disable trivial file transfer protocol (TFTP) server service.

Enable the TCP keepalives-out & keepalives-In services

Verify proxy ARP is disabled on all interfaces.

Verify no tunnel or loopback interfaces are created without any strong technical reason.

5.10 Port Security

Following configuration shall be implemented to ensure the port security

Unused ports shall be shut down

Disable the Trunk on the switch port and explicitly enable on required port only.

Configure Portfast on port which terminates to workstations, servers.

Configure BPDU guard to disable ports which are not supposed to receive BPDU’s

Enable DHCP snooping and DHCP relay if required.

Functionality to mitigate ARP poisoning shall be implemented.


Page 13 of 17

Enable root guard and loop guard

Implement the port security on switch to limit the number of valid MAC address allowed on a port.

Implement the SNMP trap, Syslog & email alert (via NMS) for this type of port security violation alert.

5.11 Virtual Local Area Network

VLAN 1 shall not be used for either out-of-band management or in-band management or User VLAN.

Only specific trunk port shall be allowed to carry the management VLAN traffic instead of all the trunk

ports

All the inactive interfaces shall be assigned to an unused Layer 2 VLAN other than VLAN 1 and shall

be in shut down state.

For certain security instances where similar systems located in same VLAN do not need to interact

directly, private VLAN shall be implemented to ensure the additional protection.

Traffic on dedicated native VLANs shall be tagged

5.12 Virtual Trunking Protocol (VTP)

VTP shall be in transparent mode

If VTP is required, then it shall be ensured strong password is implemented for VTP management

domain.

Vlans shall be pruned from switches where vlans are not used.

VTP version 2 shall not be enabled on a network device unless all of the network devices in the same

VTP domain are version 2-capable

5.13 Trunk Configuration

Auto-Trunk negotiation shall be disabled (such as DTP for cisco switches).

Non-trunk interfaces shall be placed in permanent non-trunk mode without negotiation.

Trunk interfaces shall be placed in permanent trunk mode, without negotiation.


Page 14 of 17

VLAN 1 shall not be configured as native vlan on any trunk

VLAN 1 shall not traverse across the trunk.

A unique native VLAN for each trunk on a switch shall be used

5.14 System Availability

Assure that even the lowest priority processes get some processor time in event of flooding attack.

Flow Control shall be turned off on each interface.

Unidirectional Link Detection (UDLD) shall be disabled globally and on every interface where it is not

required.

To help prevent the SYN Flood attack, the reasonable amount of time shall be set, for which the switch

will wait while attempting to establish a TCP connection.

Quality of Services shall be enabled for Voice traffic.

To help protect against DoS Attacks, and to allow it to support the widest range of security services,

the switch shall be configured with the maximum amount of memory possible.

5.15 Spanning Tree Protocol

Following configuration shall be carried for STP

Enable STP Portfast Bridge Protocol Data Unit (BPDU) Guard feature globally & individually on ports

which are not connected to another switch.

Enable Monitoring (via Syslog & email alert) & recovery mechanisms for the port which are violating

this feature.

Enable STP Root Guard feature on all the ports which are connected to another switch and protect

those switches to become a STP root switch.


If Device is configured as dedicated L2 switch, all Layer 3 features shall be disabled.


Page 15 of 17


protocol traffic.

The neighbouring device authentication should be enabled to protect the integrity of a routing domain.

The neighbouring device authentication key should be distributed manually.

Message Authentication Code Message Digest 5 (MD5) Authentication should be enabled for OSPF,

EIGRP & RIP v-2.


enabled for IS-IS.

The route learning on unused interface shall be disabled





Critical services shall be defined and prioritized using QOS.

Traffic shall be prioritized and policed as close to the end-point as possible and implemented throughout

the network with common policy settings

Devices shall be able to map COS (Class of Service) values (i.e. VLAN priority) to layer three devices

for further processing and network-wide preferences.






level’s Syslog trap on all switches

Define the source IP address to be used for syslog messages. This will typically be a loopback or an

OOB interface to ensure consistency.


Page 16 of 17



The syslog server shall be hardened and cryptographic techniques to be considered for log protection

Enable the Syslog facility to direct logs from each Switch to at least one log host, which shall be a




Enable the sequence reference number for each of the Syslog generated by switch device

The buffered logging shall be enabled for notification logs and the buffer log size shall be set to at least

16000.



Logging features on ANSP network switches shall capture all packets dropped or denied by the switch,


5.18 Authentication, Authorization and Accounting





The authentication, authorization and accounting (AAA) services shall be bound to the loopback

interface.

Users shall integrate with the system wide AAA


User accounts shall be assigned with minimal privileges, and only in accordance with operational

needs.



A local user account shall be created with privilege level 1 for emergency access in case of AAA server

unavailability. Local user shall not be configured with more than privilege level 1.


Page 17 of 17

Periodically review the administration and device command logs activity on AAA server.


End of Document

MSB | TPDS/VA | V0.2 Issue Date: 01/ 2018

Page 1 of 8


Third Party Data Sharing and Vendor Access

MSB-TPDS/VA V0.2


Page 2 of 8


Issue


V0.1 26/11/2017 GCAA – UAE

V0.2 31/01/2018 GCAA‐UAE

Reviewers


Approvals


Distribution


Amendments







Page 3 of 8

TableofContents1. Introduction .......................................................................................................................................... 4

2. References .......................................................................................................................................... 4

3. Abbreviations and Acronyms ............................................................................................................ 4

4. Change Management ........................................................................................................................ 5

5. Responsibilities and Roles ................................................................................................................ 5

6. MSB Directives ................................................................................................................................... 5

5.1 General Use, Ownership and Compliance ............................................................................. 5

5.2 Human Resource (HR) Security .............................................................................................. 6

5.3 User Access Management ........................................................................................................ 7

5.4 Password Security ..................................................................................................................... 7

5.5 Network Security ........................................................................................................................ 7


Page 4 of 8

1. Introduction

ANSP’s shall consider their information resources (i.e. information maintained in non-electronic and

electronic form and systems that process, store, or transmit such information) important assets that need

to be secured. Information Security (IS) is an ongoing process of implementing necessary controls to protect

information assets from potential risks that can adversely impact concerned stakeholders or business

operations. The ANSP’s Management is committed to strengthen its security posture.

This Document is compiled with an intent to provide guidelines to prevent unauthorized access to the

ANSP’s data/information or any information assets through the establishment of minimum controls for third

parties or vendor access to the operational environment.

2. References

ICAO Annex 17

ICAO Doc 9985





ANS Air Navigation Services

ATM Air Traffic Management

CNS Communication Surveillance Navigation

HR Human Resources

ID Identity

IS Information Security

IT Information Technology



Page 5 of 8




of that state


CNS Department is responsible for implementing and maintaining the MSB defined in this document. This

MSB document shall be reviewed,

Annually,

Depending on changes incorporated in the environment

6. MSB Directives

This document is intended to guide ANSP’s and third party/vendors to secure their information assets from

any breach or gain of confidential data while having a legitimate access to the ANSP’s infrastructure.

The below guidelines aim to build a framework that assures the secure access of required information set

by third party and ensure the protection of the ANSP’s system from intrusions and external threats.

5.1 General Use, Ownership and Compliance

Third Parties or Vendors shall be aware that the data they create on the ANSP’s systems remains the

property of ANSP. This information is not private and at any time, with or without notice, shall be

monitored, searched, reviewed, disclosed, or intercepted by the ANSP for any legitimate purpose. The

ANSP shall at all times be committed to respecting the rights of its employees, including their

reasonable expectation of privacy.

All Third Parties or Vendors of the ANSP’s information systems shall be responsible and liable for all

actions including transactions, information retrieval or communication performed on the ANSP’s

systems by using their user ID(s) and password(s).

Use of the ANSP’s assets for sending, procuring or forwarding material, statements, messages or

images that may include (but not limited to) content that is offensive, defamatory, harassing or

threatening or is in violation of applicable states laws, is strictly prohibited.

Third Parties or Vendors shall abide by the respective state’s laws including (but not limited to)

intellectual property rights, copyright issues, piracy, trade secrets and patents.


Page 6 of 8

Use of the ANSP’s account to make fraudulent offers on products, items, or services is strictly

prohibited.

Third Parties or Vendors initiating new projects (involving a mission critical system) shall liaise with IS

team to ensure Security Risk Assessment is performed as part of project planning.

Information asset owner shall be accountable for protecting information and ensuring that its

confidentiality and integrity are maintained, unless delegated to an appropriate custodian.

The respective CNS Team shall be accountable for maintaining ATM systems used for providing

business services.

Third Parties or Vendors shall be responsible for IT assets (such as laptops, ANSP provided mobile

devices, etc.) in their custody.

Third Parties or Vendors are advised not to download and store personal information on ANSP provided

IT Systems.

Third Parties or Vendors shall adhere to the ANSP’s information security policies and procedures.

Third Parties or Vendors requesting any exception or exemption from the ANSP’s information security

policies and procedures shall submit a security waiver form.

5.2 Human Resource (HR) Security

The ANSP reserves the right to perform security and/or reference checks on any end user requiring

access to their information, systems and/or premises.

Employees shall undergo mandatory Information Security awareness training as part of HR induction

and annual awareness campaign. Employees, contractors, consultants, and any third-party staff shall

acknowledge and abide by the ANSP’s End User Security Standard.

Third Parties or Vendors shall return all ANSP provided assets, in their possession, upon termination

of their employment, contract or agreement.

The ANSP’s management reserves the right to invoke HR disciplinary action (including revocation of

access/privileges) on any end user at any time in case of breach of the ANSP’s information security

policies or procedures.


Page 7 of 8

5.3 User Access Management

Third Parties or Vendors shall be responsible for the login credentials (user ID and password) assigned

to them and shall ensure the credentials are not shared among Third Parties or Vendors.

For issuance of a new login credential, the ANSP’s formal access registration (CNS requisition form)

process shall be followed.

Access (logical and physical) shall be disabled upon termination, end of contract or if Third Parties or

Vendors are identified as not reachable or absent without official leave for more than 5 continuous

business days.

5.4 Password Security

Third Parties or Vendors shall not create passwords based on personal information, names of family,

friends, birth dates, etc.

Third Parties or Vendors shall not create passwords that are a word in any language, slang, dialect,

jargon, etc.

Third Parties or Vendors shall change passwords as soon as they are suspected of being disclosed.

Third Parties or Vendors shall consider passwords as confidential information and shall not disclose

them, regardless of any circumstances. Third Parties or Vendors shall not store passwords on any

unencrypted information system or device or include in any form of electronic communication.

5.5 Network Security

Intentional or unintentional security breach or disruption to the ANSP’s corporate network is strictly

prohibited.

Mobile devices personally owned by Third Parties or Vendors should be permitted to connect to ANSP’s

guest network only.

Third Parties or Vendors shall use the ANSP’s VPN for connecting to its corporate network remotely.

Prior to the remote connection, third parties or vendors shall notify CNS team via email about their

exact login time, reason of login, expected duration of stay in the network, resources need to be

accessed and activities need to be performed


Page 8 of 8

The remote login activity shall be followed by a brief report describing the exact details of the activities

performed, its consequences (if any) and further actions (if required)

End of Document

MSB | WAF | V0.2 Issue Date: 01/ 2018

Page 1 of 6


Web Application Firewall

MSB-WAF V0.2


Page 2 of 6

Document Control

Signing in the respective section below confirms that you have read the document fully and approve its contents.

Issue


V0.1 26/11/2017 GCAA – UAE

V0.2 31/01/2018 GCAA‐UAE

Reviewers


Approvals


Distribution


Amendments







Page 3 of 6

TableofContents1. Introduction .......................................................................................................................................... 4

2. References .......................................................................................................................................... 4

3. Abbreviations and Acronyms ............................................................................................................ 4

4. Change Management ........................................................................................................................ 5

5. Responsibilities and Roles ................................................................................................................ 5

6. MSB Directives ................................................................................................................................... 5


Page 4 of 6

1. Introduction

This document details the Minimum-Security Baselines for ANSP Web Application Firewalls. This baseline

control document shall be used as a guideline for configuration of Web Application Firewalls to ensure the

deployment of industry best practices.

2. References

ICAO Annex 17

ICAO Doc 9985





AAA Authentication Authorization Accounting ANS Air Navigation Space


DDoS Distributed Denial of Service

DOS Denial Of Service

HTTP Hyper Text Transfer Protocol


IP Internet Protocol

LDAP Light Weight Directory Access Protocol


OWASP Open Web Application Security Project

SANS SANS Institute

SSL Secured Socket Layer

WAF Web Application Firewall

WASC Web Application Security Consortium


Page 5 of 6




of that state




Annually,


6. MSB Directives

This document is intended to guide supplier/CNS to secure the Web applications via WAF from external

threats, attacks and unauthorized access. CNS/Supplier shall use this baseline control document, as a

minimum, while deploying Web Application Firewalls.

Following the below guidelines should assure the (best possible) secure environment for web applications

and would assist ANSP’s to prevent external intrusions to the best possible extent.

The feature of HTTP requests processed per second shall be enabled and measured.

Peak load times on the application access behavior shall be measured and gauged.

Based on the solutions for application scanning, FW shall be configured to blacklist attack signatures

The protection parameters against vulnerabilities listed within OWASP, SANS and WASC shall be

enabled.

SSL encryption enforcement policy shall be enabled for all the client/server requests and responses.

Input validation and output encoding shall be enabled to ensure the avoidance of malicious characters

and scripts injections.

Session timeout (for active and inactive sessions) shall be enabled and specified.


Page 6 of 6

Policies and profiles related to DOS and DDoS protection within WAF appliance shall be enabled to

safeguard the organization against DOS attacks on applications.

WAF appliance shall be integrated with services like threat feeds and IP reputation.

IP based or geo based restriction should be enabled after in-depth traffic analysis. For instance,

blacklisting/whitelisting the traffic from specific IP addresses or countries to protect against attacks from

specific locations.

Auto load balancing feature shall be enabled within WAF appliance.

Complete feature set of Authentication, Authorization and Accountability (AAA) as per OWASP and

WASC framework shall be enabled

Centralized AAA model (such as RADIUS) should be activated.

Anti-Web Defacement alerting mechanism shall be enabled before hosting the WAF solution in live

environment.

The WAF appliance shall log all types of events and incidents and shall trigger an alert (such as sending

email to admin, audible alert) in case of any anomalies or unusual behavior towards web application.

Within the WAF appliance, the false positive alerts shall be monitored and analyzed.

Service level agreement shall be in place with supplier for monitoring, reporting, incident handling and

forensic analysis.

-END-