Abbreviation/Acronym

Definition

API

Application Programming Interface

AUP

Acceptable Usage Policy

DDOS

Distributed Denial of Service 

DNS

Domain Name System

HTTP

HyperText Transfer Protocol

HTTPS

HyperText Transfer Protocol Secure

IT

Information Technology

LAN

Local Area Network

MFA

Multi-Factor Authentication

MDM 

Mobile Device Management

OWASP

Open Web Application Security Project

PIM

Privileged Identity Management

PVMG

Patch and Vulnerability Management 

RBAC

Role-Based Access Control

RMS

Rights Management System

SFTP

Secure File Transfer Protocol

SIEM

Security information and event management

SSL

Secure Sockets Layer

VAPT

Vulnerability Assessment and Penetration Testing 

WAF

Web Application Firewall

XDR

Extended detection and response

ASSESSED PRIORITY

PRIORITY DESCRIPTION

TIMELINE

EMERGENCY

Critical priority Common Vulnerability Scoring System (CVSS) exploit information is notified; AND

‘Zero day’ vulnerability affecting hardware/software used by organization ; OR

Vulnerability being actively and successfully exploited by threat actors to breach the organization or other integrating organization’s

Cyber Security Team and PVMG shall jointly agree whether vulnerability and associated patches meet criteria for using the P0 Crisis Management process, and jointly agree deadlines for deployment.

Time from patch issue to deployment shall not exceed 7 calendar days under any circumstances.

Normal levels of patch testing may be reduced or removed due to the level of risk posed by not patching.

CRITICAL

Potential for Intolerable/Major business impact; OR

High value information at actual or potential risk of exposure; OR

Critical rated vulnerability is identified

Deploy without undue delay and as soon as testing has shown patches to be safe. Deadline for deployment shall be jointly agreed between the Cyber Security team and PVMG on a case by case basis.

Deployment timeline shall never exceed 15 calendar days under any circumstances.

HIGH

Potential for Significant business impact; OR

Valuable information at risk of exposure; OR

High rated vulnerability is identified.

Remediation shall be applied within 30 calendar days  and within 90 calendar days if internally exposed.

MEDIUM

Potential for Moderate business impact; OR

Valuable information at limited risk of exposure; OR

Medium rated vulnerability is identified.

Remediation by software update: Next Planned Lifecycle software update or release. 

Remediation by configuration hardening: within 90 calendar days internet exposed, within 180 calendar days internally exposed. 

LOW

Potential for Minor business impact; OR

Valuable information may be at risk of exposure; OR

Low rated vulnerability is identified.

Remediation by software updates: next Planned Lifecycle software update or release.

ENTITY   

SECURITY ROLE   

Employees/ Contractors/ Third Parties 

1. Responsible for securing the USERID and password issued to them for access to OpenMRS and information systems.    

2. Comply  with  the requirements of policies, confidentiality/nondisclosure agreement & acceptable usage policy which is signed by all staff. 

3. Obtain approval for access request forms from line manager or departmental head, information owner and system custodian.  

4. To refrain from using another employee’s USERID and/or password or sharing their own.  

5. Request for system access revocation or privilege change whenever the employee changes job roles  

Information Owners

1. Establish the rules of behavior for the appropriate use and protection of the information or data in the information systems owned.  

2. In conjunction with the users’ line managers, decide who should have access to the information system and determine what type of privileges or access rights are to be granted based on job role.  

3. Maintain and update access matrices for information systems under their jurisdiction.  

4. Perform review of system access based on the access matrices, at least monthly or bimonthly depending on system categorization.  

5. Ensure movers get necessary approval for system access and that redundant access is revoked; this is in conjunction with the HR communication.  

6. Ensure leavers are de-registered from applications, systems, shared folders and mailing lists via communication to appropriate system custodian.  

7. Ensure monthly and bimonthly user access reviews are done on time for all systems under their care and notifications sent to the relevant system custodians for action.

Human Resources 

1. Send revocation request, via established communication channels, on leavers and movers to system custodians, information owners and appropriate line managers to facilitate user access de-registration.  

2. Send access requests to system custodians for account creation.  

3. Ensure all staff (permanent, temporary or contractors) have signed the confidentiality agreement and acceptable usage agreement prior to granting of system access.  

4. Ensure all staff (permanent, temporary or contractors) have signed the confidentiality agreement and acceptable usage agreement prior to granting of system access.  

System Custodians

1. Ensure timely granting or revoking of user access based on officially documented requests.  

2. Review user access for all users monthly or bimonthly (depending on system categorization) by seeking confirmation from information owners who maintain the access matrices.  

3. Approve, monitor, and log events for user accesses as detailed in corporate standards and policies.  

4. Ensure shared drives/folders, servers, applications, or any other system resources have designated information owner(s) before creation or installation. 

5. Ensure de-registration of staff (movers and leavers) includes revoking redundant access from applications, systems, shared folders, mailing lists and other IT resources.  

6. Maintain remote access (VPN) register for all VPN users.  

7. Where possible, automate the user account management process for easier and effective access management.   

1. Management Plane controls 

1.1  Infrastructure Protection 

1.1.1 

Configure the hostname of the device

It is suggested to define the name of the device following the VCNO node naming convention. Each device’s hostname should contain the country’s initials, the city’s initials, the type of the device (FW for Firewall) and the number of the node 

Required for identification purposes

M

1.1.2

Configure a management IP address 

Set an IP address for management purposes on the devices; this IP address must be on a segregated subnet and management traffic must not go via production interfaces and must adhere to the zoning standard. 

Setting a management IP segregates management traffic and data traffic whilst preventing snooping.

M

1.1.3

Require a loopback address

To ensure continuity of source addressing of the services on the firewall, a Loopback address should be used

Issues can arise if services do not use the same source address, it can potentially cause packets to be handled incorrectly by receiving hosts.

R

1.1.4

Configure login banner 

Display a warning banner when a user connects to the device. The warning banners must be the same on all Firewalls

In some legal jurisdictions it can be impossible to prosecute and it is illegal to monitor malicious users, unless they have been notified that they are not permitted to use the system. 

M

1.1.5

Set at least two IP name servers 

Specify the address of two name servers to use for name and address resolution. The local or the zone internal servers must be used and should be located in separate geographical locations to provide resiliency 

Defining a name server ensures that the authorized/designated server responds to the client request.

R

1.1.6

Configure thresholds for load monitoring 

The network element must generate an event if the amount of CPU usage or memory usage breaks the operator- configured threshold.

Running low in memory is usually caused by increased traffic, which can potentially be an indication of DDoS attack.

M

1.2 Password Policy

1.2.1

Encrypt configuration passwords 

The strongest password encryption method must be applied to all passwords, based on the device’s capabilities, including username passwords, authentication key passwords, the privileged command password, console, virtual terminal passwords, etc. 

Passwords must always be encrypted and they shall never be displayed in plain text, therefore preventing a non-authorised user from having visibility of the passwords.

M

1.2.2

Create a fall back account

Create a local user for fall back access purposes.

The local (fall back) account can be used to access the device if all AAA servers become unavailable, providing emergency access. 

M

1.2.3

Set an encrypted management password 

Define the management or root password for the device. The strongest encryption method must be used, based on the device’s capabilities.

The management password is used to gain access to the exec shell, or equivalent, using the console or a remote connection. 

M

1.3 Unnecessary services 

1.3.1

Disable HTTP web management service and use HTTPS where possible  Disable HTTP web management service and use HTTPS where possible 

Disable the HTTP service, which is an unsecure protocol and shall not be used to manage firewalls. Use HTTPS web management to ensure data is protected across the network.

Unnecessary services must be disabled, if not needed, to prevent exploitation of vulnerabilities, as they can be used to launch DDoS and other attacks.

M

1.3.2

Disable DHCP Server and DHCP relay services 

Disable DHCP server, which are used for dynamic IP assignment, as only dedicated DHCP servers must be able to provide IP addresses to other devices

Unnecessary services must be disabled, if not needed, to prevent exploitation of vulnerabilities, as they can be used to launch DDoS and other attacks

M

1.3.3

Disable DDNS services  

DDNS should not be used within private address space to prevent inconsistent configurations between services.

Unnecessary services must be disabled, if not needed, to prevent exploitation of vulnerabilities, as they can be used to launch DDoS and other attacks. 

M

1.3.4

Disable the neighbor discovery protocols for external facing interfaces 

The exchange of device information via neighbor discovery protocols must be prohibited via external interfaces (Internet, 3rd party access, external leased line). 

Neighbor discovery protocols must be disabled unless explicitly required, as the protocol can potentially leak device information to rogue users on the network.

M

1.3.5

Prohibit telnet connections 

Define that remote connection can be established to the firewall only via secure protocols. 

Only secure communications must be allowed, in order for the traffic to be encrypted and protected from sniffing attacks.

M

  1.4 Connection security 

1.4.1 

Enable TCP keepalives for inbound and outbound connections where supported

TCP keepalives must be configured, as they check that the device on the remote end of the connection is still accessible

Enabling TCP keepalives ensures that half−open or embryonic connections are deleted by the device.

M

1.5 Interactive Management Sessions 

1.5.1 

Enable SSH Version 2 

Only secure connections must be allowed.

  SSHv2 is considered to be more secure than the v1 which is known to have vulnerabilities. 

M

1.5.2

Generate encrypted key for SSH 

Generate an encrypted key to be exchanged during SSH communication initiation. 

Data is transferred encrypted via SSH communication

M

1.5.3

Define inactivity time out for both console and remote sessions 

A predefined inactivity time-out period must be configured on the firewall to logout remote sessions that have been left idle.

Required for ensuring that the session is used by an authorized user and has not been left unattended. 

M

1.5.4

Define the allowed authentication retries for SSH connections 

Specify the number of attempts a user has before the connection resets.

This ensures that after a set number of attempts the SSH session is disconnected and possible brute force attacks are prevented.

M

1.5.5

Use authentication method for both console and remote management sessions

Define a specific password for remote authentication and specify that an AAA method must be used for authenticating user login via interactive management sessions. 

Necessary service for authenticating and identifying remote login users.

M

1.5.6

Forbid the installation of externally sourced scripts, other than provided by the manufacturer or sanitized first before use

  Scripts can be useful to perform tasks on the device but should only be used under specific circumstances

Externally sourced scripts may have malicious content and should not be installed onto the system under any circumstances.

M

1.6 AAA  

1.6.1

Set the source IP address for the AAA server 

Associate an interface’s IP address to the packet sent to the AAA server regardless of which interface the packet exited the device facilitating the analysis of the logs.

Specifying the address that the device sources management traffic from, ensures that the network can be configured in a prescriptive manner, reducing an attacker’s opportunities

M

1.6.2

Authenticate communication with AAA server

Define a key to be used for communication with the AAA server in- line with password policy 

Communication with the AAA server must be authenticated prior to exchange of any messages for assuring the communication security. 

M

1.6.3

Define the login authentication method to be AAA compliant 

Define that the AAA method must be used for login authentication and for gaining access to the privilege/configuration mode. 

The default authentication method must be AAA compliant, since it provides better security when transferring the packets and supports multiple communication protocols

M

1.6.4

Enable user authorisation 

Authorize a user’s actions depending on the permissions granted from the AAA server, only if he has been authenticated first. 

Ensures that appropriate authorisation and permissions are being granted to the user when accessing the device.

M

1.6.5

  Enable accounting to monitor the user’s actions

Provide information about the user’s actions including authorisation failure, configuration commands, system changes and all the connections made from the network access server, ensuring that periodic updates are sent to the AAA server. 

Information logged by the AAA accounting options can be valuable during the investigation of an attack. 

M

1.7 Logging  

1.7.1

  Define the time zone 

Time zone information shall be expressed in universal time coordinates (UTC) in alignment with NTP servers 

Necessary for synchronizing the log files. Accurate timekeeping is critically important for correlating network events.

M

1.7.2

  Configure timestamps for logging 

Attach timestamp information to the log and debug files. Timestamp information shall express absolute time, not time since the last power-on / reboot of the network element.

Necessary for auditing purposes and for identifying the exact time during which a change took place

M

1.7.3

Logs must be sent to at least two logging servers

Logs should be replicated on at least two logging servers to provide redundancy of events for resiliency purposes.

Logging is critical to device security because it creates an audit trail of system activity. 

M

1.7.4

Set the source IP address for the syslog

An interface’s IP address must be associated with the packet sent to any external device, regardless of which interface the packet exited the device, facilitating the analysis of the logs. 

Specifying the address that the device sources management traffic from ensures that the network can be configured in a prescriptive manner, reducing an attacker’s opportunities.

M

1.7.5

Configure notifications to be sent to a syslog server 

Send logs to syslog server above warning messages including errors, critical & emergencies. 

Allows the administrator to focus on and process the logs that need immediate attention/action and which might pose a security risk. 

M

1.7.6

Enable the logging for all interactive management sessions 

Logging on interactive management sessions must be enabled

Logging is critical to device security because it creates an audit trail of system activity.

M

1.7.7

Define names for firewall policies, where supported

Firewall policy should be named; the name should be the ticket reference from where the policy change was requested.

Naming the firewall policies is required to create an audit trail to allow for changes on the firewall policy to be tracked.

R

1.8 Border Device Filtering 

1.8.1

Enable anti-spoofing for both inbound and outbound traffic where supported 

  Verify that both inbound and outbound traffic from the network has a valid source address. 

Filtering denies any traffic that does not have the source address that was expected on a particular interface

M

1.8.2

Unicast Reverse-Path Forwarding where supported

  Ensure RPF is enabled to verify source addresses. 

A number of different attacks rely on spoofing the traffic source address. By verifying the source address it will enable the firewall to drop attack traffic. 

R

2 Control Plane controls

2.1 Border Gateway Protocol (BGP)

2.1.1

Enable BGP Authentication 

Authentication between BGP neighbors should be enabled; MD5 password authentication or keychain must be used to secure BGP sessions. 

Authentication between BGP neighbors should be enabled; MD5 password authentication or keychain must be used to secure BGP sessions. 

M

2.1.2

Enable logging for neighbor changes, if applicable 

The device must be configured to log BGP neighbor resets. 

Logging of neighbor changes ensures that all changes are retained and facilitates investigation of a potential attack.

M

2.1.3

Maximum prefixes limit must be enforced for external connected peers 

A limit must be applied regarding how many BGP prefix records a firewall can store in its memory. Must be used on all customer BGP sessions 

Limiting the BGP prefixes is required for ensuring the effectiveness and the functionality of the firewall. 

M

Limit BGP AS path length for external connected peers, if applicable 

Maximum AS path length should be configured to protect elements from errors and mis-configuration. 

Overlong AS paths should not be expected in normal circumstances and are symptomatic of problems within external networks. 

2.1.4

Specify a Time to Live, if unavailable use maximum number of hops for eBGP peers. 

A maximum TTL should be configured so that BGP packets are received from directly connected peers. 

This prevents the firewall from receiving potential malicious or false BGP advertisements and reduces the possibility of the device receiving false firewall updates that would allow an attacker to potentially corrupt the route tables, compromise network availability or redirect network traffic. 

M

2.2 Interior Routing Protocol Security 

2.2.1

Neighbour Authentication 

Neighbor authentication, such as MD5 password or key authentication, depending on the firewalls capabilities, must be used between neighboring devices exchanging routing protocols updates

A strong authentication algorithm will enhance the connection security and ensure that routing messages are exchanged between only authorized neighbors. 

M

2.2.2 

Enable routing only on participating interfaces 

Explicitly enable routing updates for those interfaces that need to participate in the routing updates. 

Ensures that only authorized interfaces participate in the routing procedure, protecting the network from receiving rogue updates. 

M

2.2.3

Enable routing updates only on the participating interfaces

Ensure that non-participating interfaces in routing updates are passive and packets are not sent or received on those interfaces. 

This prevents an interface from sending or receiving packets if it has not been specifically allowed, reducing the size of the device's attack footprint. 

R

2.3 NTP 

2.3.1

Configure at least two NTP servers or create specific NTP access groups 

Configure two NTP servers, which are part of the relative zone in which the device belongs, with one being preferred. Should be located in separate geographical locations to provide resiliency. 

Accurate and reliable time is required in order to ensure that logs can be compared across systems when investigating potential attacks. Using at least two servers provides redundancy. 

M

2.3.2

Authenticate NTP communications

Create an encrypted NTP authentication key and authenticate all NTP connections via the configured key

NTP authentication shall be configured to provide assurance that NTP messages are exchanged between trusted NTP peers, reducing an attacker’s opportunity to affect timestamps on system logs or affect other time-dependent services.

M

2.3.3

Disable NTP on external interfaces

Block an interface from sending or receiving NTP messages. 

  Reduces the footprint of the device by limiting the interfaces it sends NTP packets out of internal interfaces only. 

M

2.3.4

Configure the source address for NTP 

An interface’s IP address must be associated with the packet sent to any external device, regardless of which interface the packet exited the device, facilitating the analysis of the logs. 

By assigning a specific source interface to messages, consistent device identification is ensured and logging management is simplified. 

M

3 Data Plane Controls

3.1 Layer 2 Security 

3.1.1

Disable unused ports 

Disable all unused ports and place them in an unused state that is isolated from the rest of the network. 

Unused interfaces shall be disabled to prevent unauthorized use. 

M

3.1.2

Do not use default VLANs for management traffic 

Set a secure VLAN for management purposes and disable VLAN 1 which is the default in most of the firewall devices. 

Setting a management VLAN segregates management traffic and data traffic and prevents snooping. 

M

3.1.3

Configure interfaces to be in the correct zone 

External interfaces must be identified as untrusted and all internal interfaces must be configured in accordance with the VCNO Zoning Standard. 

By identifying interfaces as untrusted it enables screening to be performed on traffic.

M

3.1.4

Disable source routing

IP source routing must be disabled. 

This feature must be disabled as an attacker can exploit the IP options to affect the way a device forwards the packets and avert security controls 

M

3.2 Connection Controls

3.2.1

Limit concurrent sessions from singular external client 

Limits should be placed on client connections to protect flooding the network.

Attackers can attempt to flood the network causing a denial of service with connections if thresholds are not in place. 

M

3.2.2

Limit the amount of connections received on external interfaces

Limits should be placed on incoming connections to protect flooding the network. 

Attackers can attempt to flood the network causing a denial of service with connections if thresholds are not in place. 

M

3.2.3

Limit the amount of connections sent on external interfaces 

Limits should be placed on outgoing connections to protect flooding the network. 

Services can flood the network causing a denial of service with connections if thresholds are not in place. 

M

3.2.4

Limit requests per second on external interfaces 

Limits should be placed on the number of outgoing connections per seconds to protect flooding the network. 

Services can flood the network causing a denial of service with connections if thresholds are not in place.

M

3.2.5

Screen on untrusted and semi-trusted interfaces on external interfaces 

Screening should be performed on non-trusted interfaces. 

Screening is mandatory on non-trusted network to protect against malicious traffic, 

M

Mandatory Requirement (MR)

Technical Requirement 

MR1

Web application input and output must clearly define how to handle and process data based on type, content, and applicable laws, regulations and policy compliance 

MR2 

All web applications must be designed to handle authentication in a secure manner and apply access and authentication best practices

MR3 

All web applications must be designed to handle authorization in a secure manner and apply access and authentication best practices 

MR4 

All web applications must include secure session management requirements

MR5 

All web applications must apply input validation controls such as HTML entity encoding, checking for correct syntax, strongly typed data and that numbers are correctly signed within range boundaries 

MR6 

Output encoding for web applications must occur close or adjacent to the interpreter

MR7

Web applications which use systems language or unmanaged code must apply memory, string and unmanaged code requirements 

MR8 

Web applications must prevent insecure deserialization 

MR9

Web apps must apply approved cryptographic algorithms, modes and libraries

MR10 

Error handling and logging must be protected and handled securely per its data classification 

MR11

Client-side data protection must be applied 

MR12 

Sensitive data must be protected from being created, read, updated or deleted without authorisation 

MR13 

All client communication must only take place over encrypted communication paths and apply Transportation Layer Security Hardening Guide 

MR14 

Secure connections to and from monitoring systems, management tools, remote access and SSH, middleware, database, mainframes, partner or external source systems must be in place  

MR15

Software code itself must satisfy integrity controls (e.g. checksum, HMAC, encryption, digital signature) to ensure that the data has not been tampered with and is the same as before 

MR16 

Applications must be protected against common attacks such as executing unsigned code from untrusted sources and sub-domain takeovers

MR17 

Business logic flow must be sequential, processed in order and must not be bypassed and include limits to detect automated attacks 

MR18

Untrusted file data obtained from untrusted sources must be stored outside the web root.

MR19 

Applications must use Trusted Service Layer APIs (e.g. JSON, XML, GraphQL) and must have adequate authentication, session management and authorisation of all web services

MR20

Application build and deployment must be performed in a secure, repeatable, automatable build environment 

MR21

Dependencies must be managed using a dependency checker during build or compile time

MR22

Production environments must be hardened to protect against common attacks and unintended information disclosure 

MR23

HTTP request header requirements must be validated in the application according to industry best practice

MR24

Web application server hardening guidelines must be applied using approved guidelines and Standards 

MR 25 

All applications must pass a data assurance check to prevent sensitive data leakage