30(a) Security Policy: Summary of the security policy for the proposed registry

Prototypical answer:

30(a).1. Introduction
CentralNicʹs Information Security Management System (ISMS) complies with ISO 27001. CentralNic is working towards achieving full ISO 27001 certification and has secured the services of Lloydʹs Register Quality Assurance (LRQA), a UKAS accredited certifier for its ISO 27001 certification. A letter from LRQA confirming this engagement is included in Appendix 30(a).1. Stage One of this process is scheduled during May 2012, with Stage Two occurring in July 2012. The ISMS is part of a larger Management System which includes policies and procedures compliant to ISO 9001.

30(a).2. Independent Assessment
As part of ISO 27001 compliance, CentralNicʹs security policies will be subjected to annual external audit. Further details can be found in §30(b).

30(a).3. Augmented Security Levels
DCA believes that .africa requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, DCA DotAfrica Registry will operate .africa to a high level of security and stability in keeping with its status as a component of critical Internet infrastructure.

Registry systems are hardened against attack from external and internal threats. Access controls are in place and all systems are monitored and audited to mitigate the risk of unauthorised access, distribution or modification of sensitive data assets. The Authoritative DNS System has been designed to meet the threat of Distributed Denial-of-Service (DDoS) attacks by means of over-provisioning of network bandwidth, and deployment of Shared Unicast (ʺAnycastʺ) addresses on nameservers. Whois services have been designed with built-in rate limiting and include mechanisms for protection of personal information. The stability of the registry is supported by use of high-availability technologies including a ʺhotʺ Disaster Recovery site in the Isle of Man, as well as a backup provider relationship with GMO Registry in Japan.

30(a).4. Commitments to Registrars
DCA DotAfrica Registry will make the following commitments to .africa registrars:
 The SRS will be operated in a secure manner. Controls will be in place to prevent unauthorised access and modification of registry data.
 The Whois service will prevent unauthorised bulk access to domain name registration data, and provide tools to protect personal information.
 The DNS system will be designed to provide effective defence against DDoS attacks. The registry will proactively monitor the DNS system to provide early warning against threats to the stability of .africa.
 The DNSSEC system will be operated in accordance with best practices and recommendations as described in the relevant RFC documents (described in §43).
 Security incidents reported by registrars, registrants and other stakeholders will be acted upon in accordance with the Security Incident Response Policy (see below).
 Security vulnerabilities reported to the registry will be acknowledged and remediated as quickly as possible.
 Registrars will be promptly notified of all incidents that affect the security and stability of the registry system and their customers, and will be kept informed as incidents develop.

30(a).5. Access Controls
DCA DotAfrica Registry will operate an access control policy for the registry system. For example, the web-based Staff Console which will be used to administer the SRS and manage registrar accounts will support a total of ten different access levels, ranging from ʺTraineeʺ, who have read-only access to a subset of features, to ʺSystem Administratorʺ who have full access to all systems.

Underlying server and network infrastructure will also be subjected to access control. A centralised configuration manager will be used to centrally control access to servers. Individual user accounts will be created, managed and deleted via the configuration server. Access to servers will be authenticated by means of SSH keys: only authorised keys may be used to access servers. Operations personnel can escalate privileges to perform administration tasks (such as updating software or restarting daemons) using the ʺsudoʺ command which is logged and audited as described below.

Only operations personnel will have access to production environments. Development personnel will be restricted to development, staging and OT&E environments.

30(a).6. Security Enforcement
As per CentraNic protocol, security controls will be continually monitored to ensure that they are enforced. Monitoring will include use of intrusion detection systems on firewalls and application servers. Attempted breaches of access controls (for example, port scans or web application vulnerability scans) will trigger NOC alerts and may result in the execution of the Security Incident Response Policy (see below).
DCA DotAfrica Registry will operate a centralised logging and monitoring system (see §42), analyzing access logs in order to generate access reports which will then be reviewed by NOC personnel. This will include access to servers via SSH, to web-based administration systems, and to security and networking equipment. Unexpected access to systems will be investigated with a view to correcting any breaches and⁄or revoking access where appropriate.

30(a).8. Security Incident Response Policy
DCA DotAfrica Registry will operate a Security Incident Response Policy which will apply to all events and incidents as defined by the policy, and to all computer systems and networks operated by DCA DotAfrica Registry.

The Policy will provide a mechanism by which security events and incidents are defined (as observable change to the normal behaviour of a system attributable to a human root cause). It will also define the conditions under which an incident may be defined as escalated (when events affect critical production systems or requires that implementation of a resolution that must follow a change control process) and emergencies (when events impact the health or safety of human beings, breach primary controls of critical systems, or prevent activities which protect or may affect the health or safety of individuals).

The Policy will establish an Incident Response Team which regularly reviews status reports and authorises specific remedies. The IST will conduct an investigation which seeks to determine the human perpetrator who is the root cause for the incident. Very few incidents will warrant or require an investigation. However, investigation resources like forensic tools, dirty networks, quarantine networks and consultation with law enforcement may be useful for the effective and rapid resolution of an emergency incident.

The Policy will make use of DCA DotAfrica Registry’s support ticketing and bug tracking systems to provide a unique ID for the event, and means by which the incident may be escalated, information may be reported, change control processes put into effect, and ultimately resolved. The Policy will also describe the process by which an incident is escalated to invoke an Emergency Response, which involves Lock-Down and Repair processes, monitoring and capturing of data for forensic analysis, and liaison with emergency services and law enforcement as necessary.

30(a).9. Role of the Network Operations Centre (NOC)
In addition to its role in managing and operating CentralNicʹs infrastructure, the NOC plays a key role in managing security. The NOC responds to any and all security incidents, such as vulnerability reports received from registrars, clients and other stakeholders; monitoring operator and security mailing lists (such as the DNS-OARC lists) to obtain intelligence about new security threats; responding to security-related software updates; and acting upon security alerts raised by firewall and intrusion detection systems.

30(a).10. Information Security Team
As per CentralNic, DCA DotAfrica Registry will maintain an Information Security Team (IST) to proactively manage information security. The IST will be a cross-functional team from relevant areas of DCA DotAfrica Registry operations. These key members of staff will be responsible for cascading rules, regulations and information to their respective departments. They will also be the first port of call for their departmental staff to report potential security incidences and breaches. The IST will be members of an internal email group used to co-ordinate and discuss security related issues.

The IST will comprised the CEO, CTO, Operations Manager, Senior Operations Engineer and Security Engineer.
IST responsibilities will include:
 Review and monitor information security threats and incidents.
 Approve initiatives and methodologies to enhance information security.
 Agree and review the security policy, objectives and responsibilities.
 Review client requirements concerning information security.
 Promote the visibility of business support for information security company-wide.
 Manage changes to 3rd party services that may impact on Information Security
 Perform internal audits with the assistance of Blackmores.

30(a).11 Auditing and Review
ISO 27001 includes processes for the auditing and review of security systems and policies. Audits are performed annually by an independent assessor. CentralNic’s IST periodically reviews the ISMS and conducts a gap analysis, identifying areas where performance does not comply with policy, and where the Risk Assessment has identified the need for further work. DCA DotAfrica Registry’s IST will follow the same review process.

30(a).12. Testing of Controls and Procedures
DCA DotAfrica Registry will conduct bi-annual penetration tests of its registry systems to ensure that access controls are properly enforced and that no new vulnerabilities have been introduced to the system. Penetration tests will include both ʺblack boxʺ testing of public registry services such as Whois and the Registrar Console, ʺgrey boxʺ testing of authenticated services such as EPP, and tests of physical security at DCA DotAfrica Registry’s offices and facilities.
DCA DotAfrica Registry will retain the services of a reputable security testing company such as SecureData (who, as MIS-CDS, performed the 2009 assessment of CentralNicʹs security stance). The results of this test will be used in annual reviews and audits of the ISMS.

30(a).13. DCA Security Policy
The following policy relates to DotConnectAfrica’s offices and systems rather than to the DCA DotAfrica Registry system.
30(a).13.1. Controls on Confidential Data

Data that relates to .africa are only accessible by authorized staff. Access to the system is via keys and passwords, no other staff can access the server and cabinets which store backups and confidential physical documents.

30(a).13.2. Storage of Records

Physical documents will be placed under lock and key accessible only to authorized persons. Regular auditing ensures that all information is secure.

Soft-copy data will be kept in a secured server with encryption that will ensure that data is not accessible to any third party. The server will be isolated from the rest of the network at all times to ensure that it is not accessible except for authorized access.

30(a).13.3. Storage of Credentials

Credentials to registry services are only authorized to one person who has access to the Registry Console, who works in conjunction with other staff to provide any necessary information.

30(a).13.4. Logging of Access

Access logs are monitored in a regular basis, all logins are recorded as well as a log sheets that lists the specific times that systems were accessed and the person that accessed the system.

30(a).13.5. Physical Access Controls

Alarm systems, razor fence perimeter wall with guards patrols with Alarm remote monitoring. All services are available 24x7.

30(a)13.6. Physical Security

30(a).13.6.1. Buildings

• Security, Access Control and CCTV
• Cameras installed at every entrance and at the perimeter of the facility
• Security access control is centralized
• Fence surrounds the facility backed up by security patrols.
• Logbook at entrance for records of all entrances into the Premises

30(a).13.6.2. Offices

• Proximity card with pin grants access to authorized personnel only.
• Cameras installed at every entrance into the building

30(a).13.6.3. Computer Equipment

• Proximity card with pin grants access to authorized personnel only.
• Every user has a designated workstation with monitored network access.
• Each workstation, laptops and tablet has password with a policy that all passwords must be changed in a regular period

30(a).13.6.4. Network Equipment and Infrastructure

• Equipment is located in a secured area that has an electric door with Logbook at the entrance for records of entrances into the data centre.
• No staff are allowed to access to equipment except authorized engineers
• Proximity card with pin grants access to authorized personnel only.
• All network infrastructure is secured in trunking and conduits, routine maintenance ensures that trunking is well secured and intact
• Wireless transmitters are placed beyond reach and well secured in braces.

30(a).13.6.5. Portable Media

• Staff are assigned USB sticks that are only authorized for internal storage and transfers.
• No portable media that belongs to company is allowed outside unless by express permission

30(a).13.6.6. Physical Documents

• Each business unit has a designated cabinet where they keep documents under lock and key
• All company documents are required to be filed and archived as necessary in chronological order.
• Access to these files is restricted to the said business unit unless by express authorization from the unit manager


30(a).13.7. Network Access Controls

• Network equipment is located in a secured area that has an electric door with Logbook which records all entrances into the data centre.
• No staff are allowed to access to equipment except authorized engineers
• All workstations, laptops, tablets, and printers are configured not to allow access to network settings except the network administrator.
• Firewalls, routers and all network equipment have secured passwords that are changed regularly
• Each business unit has its own VPN which restricts users from accessing beyond their VPN
• Users have access times and tickets which ensure that no one can access devices except during authorized hours.

30(a).13.8. Malware

• Staff are not allowed to access websites that are not work related and an access log for each PC is produced periodically to check this.
• Requiring the scanning of media from outside of the organization for malware before they can be used
• Requiring that e-mail file attachments, including compressed files (e.g., .zip files), be saved to local drives or media and scanned before they are opened
• Forbidding the sending or receipt of certain types of files (e.g., .exe files) via e-mail and allowing certain additional file types to be blocked for a period of time in response to an impending malware threat
• Restricting or forbidding the use of unnecessary software, such as user applications that are often used to transfer malware (e.g., personal use of external instant messaging, desktop search engine, and peer-to-peer file sharing services), and services that are not needed or duplicate the organization-provided equivalents (e.g., e-mail) and might contain additional vulnerabilities that could be exploited by malware
• Restricting the use of administrator privileges by users, which limits the privileges available to malware introduced to systems by users
• Requiring that systems be kept up-to-date with OS and application upgrades and patches
• Restricting the use of removable media (e.g., floppy disks, compact discs, USB flash drives), particularly on systems that are at high risk of infection,
• Specifying which types of preventive software (e.g., antivirus software, spyware detection, and removal utilities) are required for each type of system (e.g., file server, e-mail server, proxy server, workstation, personal digital assistant [PDA]) and application (e.g., e-mail client, Web browser), and listing the high-level requirements for configuring and maintaining the software
• Permitting access to other networks (including the Internet) only through organization-approved and secured mechanisms
• Requiring firewall configuration changes to be approved through a formal process
• Specifying which types of mobile code may be used from various sources (e.g., internal Web servers, other organizations’ Web servers)
• Restricting the use of mobile devices on trusted networks
• All workstations, laptops and servers are installed with antivirus software which automatically updates virus signature files to detect malicious software.

30(a).13.9. User Accounts and Passwords

• All the devices that are connected to the network are accessed via a domain logon which mean that they must connect to a domain and cannot be accessed as standalones unless during repairs and maintenance by authorized staff.
• Users are not allowed to have the same password on multiple systems.
• Account Lockout Policy settings, disables accounts after a specific number of unsuccessful logins. This disabled accounts can then be restored by the system administrator after proper explanation for the reasons why account was disabled
• The system has an enforceable password history to ensure that all new passwords are unique ,also there is a maximum password age after which the user is required by the system to automatically change the passwords
• Passwords must meet complexity requirements, i.e. contain Uppercase, lowercase, numerals, non-alphanumeric and Unicode characters this ensures that all passwords are strong enough.
• All accounts and devices connected to specific domains have a routine audit to ensure that vulnerabilities and illegal attempts for log in are mitigated and accessed.


30(a).13.10. Communications with Stakeholders

• Our organization has in place mechanisms to enable unrestricted access to the Local law enforcement officers that are in proximity to the organizations offices.
• DCA will establish a channel of communication and format with which to reach ICANN as the authority, these communications will include mandatory routine communications required between the registry and ICANN as per normal registry operations
• In Conjunction to above normal operations, DCA intends to communicate to ICANN in cases where there is need for urgent mitigation measures arising from issues related to running of registry, conflicts and all other issues deeded to arise in the course of normal business.
• DCA will keep a log of all relevant emails, fax and telephone numbers to be used appropriately for each communication.
• Alternative ways to complete all remittances have been made in advance shall the normal authorized channels be unavailable due to unavoidable circumstances to ensure that all regular operations are sustained.
• In cases where such measures cannot be carried out completely, appropriate notifications shall be made to ICANN or any other affected persons in advance to explain failure to perform the regular actions thereof via email.

Similar gTLD applications: (0)