cns planning and implementation in the mid region atm … sg8/cns sg8-wp12- … · navigation and...
Post on 10-Apr-2018
234 Views
Preview:
TRANSCRIPT
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
MSB | WAS | V0.2 Issue Date: 01/ 2018
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
Version Date Name Designation Signature
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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
MSB | WAS | V0.2 Issue Date: 01/ 2018
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
MSB | WAS | V0.2 Issue Date: 01/ 2018
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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
MSB | WAS | V0.2 Issue Date: 01/ 2018
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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.
MSB | WAS | V0.2 Issue Date: 01/ 2018
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
Minimum Security Baseline Document
FIREWALL
MSB-FW
V0.2
MSB | FW | V0.2 Issue Date: 01/ 2018
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
Version Date Name Designation Signature
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.
MSB | FW | V0.2 Issue Date: 01/ 2018
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
MSB | FW | V0.2 Issue Date: 01/ 2018
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
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
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
MSB | FW | V0.2 Issue Date: 01/ 2018
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 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.
MSB | FW | V0.2 Issue Date: 01/ 2018
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.
MSB | FW | V0.2 Issue Date: 01/ 2018
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.
MSB | FW | V0.2 Issue Date: 01/ 2018
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.
MSB | FW | V0.2 Issue Date: 01/ 2018
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.
MSB | FW | V0.2 Issue Date: 01/ 2018
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):
MSB | FW | V0.2 Issue Date: 01/ 2018
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
MSB | FW | V0.2 Issue Date: 01/ 2018
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
MSB | FW | V0.2 Issue Date: 01/ 2018
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.
MSB | FW | V0.2 Issue Date: 01/ 2018
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
MSB | LINUX | V0.2 Page 1 of 10 Issue Date: 01/ 2018
Minimum Security Baseline Document
LINUX OS, SYSTEMS and SERVERS
MSB-LINUX
V0.2
MSB | LINUX | V0.2 Page 2 of 10 Issue Date: 01/ 2018
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
Version Date Name Designation Signature
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.
MSB | LINUX | V0.2 Page 3 of 10 Issue Date: 01/ 2018
Table of Contents
1. Introduction ..................................................................................................................... 4
2. References ..................................................................................................................... 4
3. Abbreviations and Acronyms .......................................................................................... 4
4. Responsibilities and Roles .............................................................................................. 5
5. MSB Directives ............................................................................................................... 5
5.1 Basic Security ........................................................................................................................... 6
5.2 Operating system & Services Security ..................................................................................... 6
MSB | LINUX | V0.2 Page 4 of 10 Issue Date: 01/ 2018
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
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
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
MSB Minimum Security Baseline
NFS Network File System
SCP Secure Copy
SMRUF Type of Denial of service attack
MSB | LINUX | V0.2 Page 5 of 10 Issue Date: 01/ 2018
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
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 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.
MSB | LINUX | V0.2 Page 6 of 10 Issue Date: 01/ 2018
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.
MSB | LINUX | V0.2 Page 7 of 10 Issue Date: 01/ 2018
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
MSB | LINUX | V0.2 Page 8 of 10 Issue Date: 01/ 2018
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})
MSB | LINUX | V0.2 Page 9 of 10 Issue Date: 01/ 2018
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.
MSB | LINUX | V0.2 Page 10 of 10 Issue Date: 01/ 2018
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
Minimum Security Baseline Document
ROUTER
MSB-ROUTER
V0.2
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
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
Version Date Name Designation Signature
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.
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
Page 3 of 15
Table of Contents
1. Introduction ..................................................................................................................... 4
2. References ..................................................................................................................... 4
3. Abbreviations and Acronyms .......................................................................................... 4
4. Change Management ..................................................................................................... 6
5. Responsibilities and Roles .............................................................................................. 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
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
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
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
AAA Authentication Authorization Accounting
ANS Air Navigation Service
ARP Address Resolution Protocol
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
Page 5 of 15
CDP CISCO Discovery Protocol
CNS Communication Navigation Surveillance
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
MSB Minimum Security Baseline
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
SNMP Simple Network Management Protocol
SSH Secure Shell
UDLD Unidirectional Link Detection
UPS Uninterruptible Power Supply
VLAN Virtual LAN VPN Virtual Private Network
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
Page 6 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 Department is responsible for implementing and maintaining the MSB defined in this document. 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 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,
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 router
as an effective safeguard.
5.1 Physical Security
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:
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
Page 7 of 15
controls for temperature and humidity,
An uninterruptible power supply (UPS), and
Spare components for contingency purpose.
5.2 Operating System
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.
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.3 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.
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
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
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 Weak or poor 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.
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
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.
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
router. 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.
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.
Access-lists shall be implemented on line interface allowing only required management systems IP
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
SNMP read and write access shall be disabled.
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
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.
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.7 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.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.
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
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
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
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.
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.
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
Page 13 of 15
Unicast Reverse-Path Forwarding (UPF) Verification shall be enabled.
Proxy ARP shall be disabled on all interfaces.
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
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.
The authentication, authorization and accounting (AAA) services shall be bound to the loopback
interface.
Users shall integrate with the system wide AAA
Users shall be assigned individual user accounts
User accounts shall be assigned 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.
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.
Re-authentication of devices and users shall occur for proper intervals.
5.12 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
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
Page 14 of 15
Enable the syslog organized output on syslog server by using facility numbers. Enable information
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.
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 router 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 router 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 ANSP network routers shall capture all packets dropped or denied by the router,
and information security team shall review those logs at least monthly.
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.
MSB | ROUTER | V0.2 Issue Date: 01/ 2018
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
Minimum Security Baseline Document
SWITCH
MSB-SW
V0.2
MSB | SW | V0.2 Issue Date: 01/ 2018
Page 2 of 17
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
V1.0 26/11/2017 GCAA – UAE
V0.2 31/01/2018 GCAA-UAE
Reviewers
Version Date Name Designation Signature
Approvals
Version Date Name Designation Signature
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.
MSB | SW | V0.2 Issue Date: 01/ 2018
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
5. Responsibilities and Roles .............................................................................................. 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
MSB | SW | V0.2 Issue Date: 01/ 2018
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
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
AAA Authentication Authorization Accounting
ANS Air Navigation Service
ARP Address Resolution Protocol
CDP CISCO Discovery Protocol
CNS Communication Navigation Surveillance
COS Class of service
DoS Denial of Service
MSB | SW | V0.2 Issue Date: 01/ 2018
Page 5 of 17
DTP Dynamic Trunking Protocol
FTP / SFTP File Transfer Protocol / Secure FTP
HTTPS Hyper Text Transfer Protocol Secure
LAN Local Area Network
MOP Maintenance Operations Protocol
MSB Minimum Security Baseline
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
SNMP Simple Network Management 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
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 MSB document shall be reviewed,
Annually,
Depending on the changes incorporated in the environment
MSB | SW | V0.2 Issue Date: 01/ 2018
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,
break in and service disruption to maintain availability, confidentiality and integrity
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.
5.1 Physical Security
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:
controls for temperature and humidity,
An uninterruptible power supply (UPS), and
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
MSB | SW | V0.2 Issue Date: 01/ 2018
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.
MSB | SW | V0.2 Issue Date: 01/ 2018
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.
5.3 Operating System
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.
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.
MSB | SW | V0.2 Issue Date: 01/ 2018
Page 9 of 17
System reboots or power failure shall not affect the configuration.
Recovery procedures shall be well documented and tested.
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 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.
MSB | SW | V0.2 Issue Date: 01/ 2018
Page 10 of 17
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.
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.
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
switch. 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.
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.
Access-lists shall be implemented on line interface allowing only required management systems IP
addresses.
Log all the denied access by line interface access-list.
MSB | SW | V0.2 Issue Date: 01/ 2018
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
SNMP read and write access shall be disabled.
Due to business needs if SNMP is required for the device, then switch should be configured for SNMP
version 3 with AES128 bit encryption.
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 Network Services
Following configuration shall be implemented
Disable Unnecessary network service
Disable BOOTP services
Disable finger services
Disable DHCP services
MSB | SW | V0.2 Issue Date: 01/ 2018
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.
MSB | SW | V0.2 Issue Date: 01/ 2018
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.
MSB | SW | V0.2 Issue Date: 01/ 2018
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.
5.16 Routing and Routing Protocols
If Device is configured as dedicated L2 switch, all Layer 3 features shall be disabled.
MSB | SW | V0.2 Issue Date: 01/ 2018
Page 15 of 17
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.
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.
Hashed Message Authentication Code Message Digest 5 (HMAC-MD5) Authentications should be
enabled for IS-IS.
The route learning on 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.
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.
5.17 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
Enable the syslog organized output on syslog server by using facility numbers. Enable information
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.
MSB | SW | V0.2 Issue Date: 01/ 2018
Page 16 of 17
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 Switch 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 switch 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 ANSP network switches shall capture all packets dropped or denied by the switch,
and information security team shall review those logs at least monthly.
5.18 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.
The authentication, authorization and accounting (AAA) services shall be bound to the loopback
interface.
Users shall 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.
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.
MSB | SW | V0.2 Issue Date: 01/ 2018
Page 17 of 17
Periodically review the administration and device command logs activity on AAA server.
Re-authentication of devices and users shall occur for proper intervals.
End of Document
MSB | TPDS/VA | V0.2 Issue Date: 01/ 2018
Page 1 of 8
Minimum Security Baseline Document
Third Party Data Sharing and Vendor Access
MSB-TPDS/VA V0.2
MSB | TPDS/VA | V0.2 Issue Date: 01/ 2018
Page 2 of 8
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
Version Date Name Designation Signature
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.
MSB | TPDS/VA | V0.2 Issue Date: 01/ 2018
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
MSB | TPDS/VA | V0.2 Issue Date: 01/ 2018
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
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
ANS Air Navigation Services
ATM Air Traffic Management
CNS Communication Surveillance Navigation
HR Human Resources
ID Identity
IS Information Security
IT Information Technology
MSB Minimum Security Baseline
MSB | TPDS/VA | V0.2 Issue Date: 01/ 2018
Page 5 of 8
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 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.
MSB | TPDS/VA | V0.2 Issue Date: 01/ 2018
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.
MSB | TPDS/VA | V0.2 Issue Date: 01/ 2018
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
MSB | TPDS/VA | V0.2 Issue Date: 01/ 2018
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
Minimum Security Baseline Document
Web Application Firewall
MSB-WAF V0.2
MSB | WAF | V0.2 Issue Date: 01/ 2018
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
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
Version Date Name Designation Signature
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.
MSB | WAF | V0.2 Issue Date: 01/ 2018
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
MSB | WAF | V0.2 Issue Date: 01/ 2018
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
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
AAA Authentication Authorization Accounting ANS Air Navigation Space
CNS Communication Navigation Surveillance
DDoS Distributed Denial of Service
DOS Denial Of Service
HTTP Hyper Text Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
IP Internet Protocol
LDAP Light Weight Directory Access Protocol
MSB Minimum Security Baseline
OWASP Open Web Application Security Project
SANS SANS Institute
SSL Secured Socket Layer
WAF Web Application Firewall
WASC Web Application Security Consortium
MSB | WAF | V0.2 Issue Date: 01/ 2018
Page 5 of 6
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 MSB document shall be reviewed,
Annually,
Depending on the changes incorporated in the environment
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.
MSB | WAF | V0.2 Issue Date: 01/ 2018
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-
top related