Back

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

gTLDFull Legal NameE-mail suffixDetail
.BARPunto 2012 Sociedad Anonima de Capital Variablecentralnic.comView
Except where specified this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.

30(a).1. Introduction

CentralNicʹs Information Security Management System (ISMS) implements all the mandatory requirements of the EIC⁄ISO 27001:2005 standard. The scope of the management system covers all of CentralNicʹs registry systems and facilities. CentralNic is working towards achieving full ISO 27001 certification and has secured the services of Lloydʹs Register Quality Assurance (LRQA) for this certification. A letter from LRQA confirming this engagement is included in Appendix 30(a).1. Stage One of this process was successfully completed during May of this year and Stage Two of the assessment is scheduled to be completed by July 10th. CentralNic will provide a copy of the assessment report to ICANN for consideration, and a copy of the certificate once it has been issued.

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

Applicant believes that the TLD requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, Applicant and CentralNic will operate the TLD 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

Applicant and CentralNic will make the following commitments to the TLD 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 the TLD.
• 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

CentralNic operates an access control policy for the registry system. For example, the web-based Staff Console which is used to administer the SRS and manage registrar accounts supports 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 is also subjected to access control. A centralised configuration manager is used to centrally control access to servers. Individual user accounts are created, managed and deleted via the configuration server. Access to servers is 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 have access to production environments. Development personnel are restricted to development, staging and OT&E environments.

30(a).6. Security Enforcement

Security controls are continually monitored to ensure that they are enforced. Monitoring includes use of intrusion detection systems on firewalls and application servers. Attempted breaches of access controls (for example, port scans or web application vulnerability scans) trigger NOC alerts and may result in the execution of the Security Incident Response Policy (see below).

Since CentralNic operates a centralised logging and monitoring system (see &sect42;), access logs are analysed in order to generate access reports which are then reviewed by NOC personnel. This includes access to servers via SSH, to web-based administration systems, and to security and networking equipment. Unexpected access to systems is investigated with a view to correcting any breaches and⁄or revoking access where appropriate.

30(a).8. Security Incident Response Policy

CentralNic operates a Security Incident Response Policy which applies to all events and incidents as defined by the policy, and to all computer systems and networks operated by CentralNic.

The Policy provides 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 also defines 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 established an Incident Response Team which regularly reviews status reports and authorises specific remedies. The IST 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 makes use of CentralNicʹs existing 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 also describes 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

CentralNic maintains an Information Security Team (IST) to proactively manage information security. The IST is a cross-functional team from relevant areas of CentralNic. These key members of staff are responsible for cascading rules, regulations and information to their respective departments. They are also the first port of call for their departmental staff to report potential security incidences and breaches, the IST are all members of an internal email group used to co-ordinate and discuss security related issues.

The IST is comprised of the CEO, CTO, Operations Manager, Senior Operations Engineer and Security Engineer.

IST responsibilities 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. The 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.

30(a).12. Testing of Controls and Procedures

CentralNic 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 CentralNicʹs offices and facilities.

CentralNic 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. Applicant Security Policy
Controls to restrict access to confidential data relating to the TLD:
NDAs and confidentiality agreements with employees and service providers.

Storage of records:
Everything on the network is encrypted and password protected. All printed documents are stored in a safe with controlled access.

Controls to secure credentials used to access registry services and other third party systems:
Access will be granted only to the President, Secretary, and authorised personnel, with individual password access for each user.

Storage of credentials:
All data will be backed up on an internal server every month.

Information processing facilities to be used:
Email for most purposes. All email accounts are administrated in-house and are hosted on Rackspace dedicated servers. Some users are using Google Apps to access the email through Gmail. A dedicated employee controls access and configurations related to all email accounts.

Access controls in place to prevent unauthorised access to information processing facilities:
There is a security guard at the entrance. Visitors are required to sign in and show an ID. Closed Circuit cameras, ADT Alarm System, Deadbolt locks at all access points.

Controls in place to ensure physical security:
Fingerprint access to the building and offices.
Computer Equipment: All computers are password protected and Users have restricted access to the network
Network Equipment: Routers, Switches and Firewalls are securely placed and have restricted access.
Network Infrastructure: Secure site in the office where server for backups is located. This is protected with a firewall. All emails and web based services are hosted on Dedicated
servers in Rackspace.

Controls in place to restrict access to networks:
All Networks are configured so that Users have restricted access and are password protected.

Controls in place to mitigate the risks from malware:
Every computer users an up to date Antivirus.


Policies in place regarding user accounts and passwords:
All passwords are generated by the network administrator and users are required to change the password every three months. Logs are reviewed and when a user is inactive for more than 15 days his account is blocked.

Maintaining contacts with relevant authorities:
The President of the company will maintain contacts with relevant authorities.

gTLDFull Legal NameE-mail suffixDetail
.autoFegistry, LLCfegistry.comView
Except where specified this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.
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
Applicant believes that the TLD requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, Applicant and CentralNic will operate the TLD 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
Applicant and CentralNic will make the following commitments to the TLD 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 the TLD.
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
CentralNic operates an access control policy for the registry system. For example, the web-based Staff Console which is used to administer the SRS and manage registrar accounts supports 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 is also subjected to access control. A centralised configuration manager is used to centrally control access to servers. Individual user accounts are created, managed and deleted via the configuration server. Access to servers is 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 have access to production environments. Development personnel are restricted to development, staging and OT&E environments.

30(a).6. Security Enforcement
Security controls are continually monitored to ensure that they are enforced. Monitoring includes use of intrusion detection systems on firewalls and application servers. Attempted breaches of access controls (for example, port scans or web application vulnerability scans) trigger NOC alerts and may result in the execution of the Security Incident Response Policy (see below).
Since CentralNic operates a centralised logging and monitoring system (see &sect42;), access logs are analysed in order to generate access reports which are then reviewed by NOC personnel. This includes access to servers via SSH, to web-based administration systems, and to security and networking equipment. Unexpected access to systems is investigated with a view to correcting any breaches and⁄or revoking access where appropriate.

30(a).8. Security Incident Response Policy
CentralNic operates a Security Incident Response Policy which applies to all events and incidents as defined by the policy, and to all computer systems and networks operated by CentralNic.
The Policy provides 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 also defines 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 established an Incident Response Team which regularly reviews status reports and authorises specific remedies. The IST 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 makes use of CentralNicʹs existing 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 also describes 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
CentralNic maintains an Information Security Team (IST) to proactively manage information security. The IST is a cross-functional team from relevant areas of CentralNic. These key members of staff are responsible for cascading rules, regulations and information to their respective departments. They are also the first port of call for their departmental staff to report potential security incidences and breaches, the IST are all members of an internal email group used to co-ordinate and discuss security related issues.
The IST is comprised of the CEO, CTO, Operations Manager, Senior Operations Engineer and Security Engineer.
IST responsibilities 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. The 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.

30(a).12. Testing of Controls and Procedures
CentralNic 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 CentralNicʹs offices and facilities.
CentralNic 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. Applicant Security Policy
Fegistry has physical security measures including locked offices, visitor log, etc). Fegistry uses best practices in computer security (screen locks, password policy, & antivirus updates done regularly). Fegistry has network security (firewalls, secured wifi, secured cabling and network cabinets, network activity logging). Fegistry uses data security (encrypted storage of files and credentials).
Fegistry is working with CentralNic and other security experts to enhance site and network security measures in addition to policy development, employee training, and enhanced physical security measures.