30(a) Security Policy: Summary of the security policy for the proposed registry
|gTLD||Full Legal Name||E-mail suffix||Detail|
TABLE OF CONTENTS
30(a).1 REGISTRY SECURITY POLICY: SUMMARY
30(a).1.1 Physical Security
30(a).1.2 System Security
30(a).1.3 Network Security
30(a).1.4 Service Security
30(a).1.5 Data Security
30(a).1.6 Security Monitoring
30(a).1.7 Attack Mitigation
30(a).1.8 Personnel Policies
30(a).1.9 Security Incident Response
30(a).2 INDEPENDENT ASSESSMENT ON SECURITY CONTROLS
30(a).3 ABOUT THIS RESPONSE
- - - - -
30(A).1. REGISTRY SECURITY POLICY: SUMMARY
In order to provide end-to-end privacy and security, the Registry Service is built in accordance with recognized best practices in architectural and operational security, providing security at each level in the design and deployment. Confidentiality, integrity, and availability of registry data is of the utmost importance to us. We intend to maintain user trust and confidence.
Our Registry commits to its registrants that:
* their registration information will always be kept appropriately secure according to ICANN policy,
* that reliable global DNS service will always resolve the registered names, and
* that all changes to registration will be properly authenticated.
To meet these promises, we have minimum threshold levels of physical, network, system, service, and data security. The policies summarized here outline the thought and principles behind our security.
In broad terms, the ISC Registry Security Policy begins with the provision of multi-layered ʺDefense In Depthʺ for every element of the Registry, including:
* Physical Security
* Network Security
* System Security
* Service Security
* Data Security
Augmenting these defenses are mechanisms to detect Security Events, including:
* Centralized Logging and Log Analysis
* Network Aberration Alerting
* System Integrity Analysis
Our systems are highly redundant and are architecturally arranged to limit the effect of security events.
Should a Security Event occur, a set of Attack Mitigation mechanisms will be triggered.
For purposes of data recovery, forensic reconstruction, and event analysis we maintain deep backup, transaction journals, and audit trails.
We have a formal Security Incident Response Plan in place to resolve each incident. We subsequently review and evaluate our response to learn where we can make improvements
This TLD string does not require elevated or specialized security levels which are specific to and expected of financial and high security TLDs.
30(a).1.1. Physical Security
All registry servers are housed in carrier grade, first-tier dedicated data center spaces that are secured and monitored 24x7 by the data center vendor (by video surveillance and⁄or by guard patrols). Access is secured by an access control list, and requires a biometric scan (hand or retina) for entry. Only our own staff members are permitted to have physical access to the equipment hosted in these facilities.
Our contracts with data center vendors must all require that we be quickly notified if there is suspicious activity or an event that affects our equipment or networks.
30(a).1.2. System Security
The computer systems used by both Registry Services and SNS are enterprise-class servers running an appropriate operating system software. Maintenance of these systems follows industry standard best practices, including regular security updates, configuration management, and backups. Configuration requirements include running only the minimal set of services that are required, local firewalling, and per-user change tracking. Remote administration of the systems is done by a limited set of authorized staff, using secure channels with limited points of network ingress. Only ISC employees may have any form of access (physical or administrative) to Registry systems.
The computer systems used by both Registry Services and SNS use operating systems and applications software that have a high resistance to computer viruses or ʺrootkitsʺ.
Business office systems, which are more vulnerable, are protected by industry best practice anti-virus tools as well as by procedures to reduce system exposure or limit the introduction of viruses.
30(a).1.3. Network Security
The network elements used by Registry Services are carrier-grade routers, switches, and load balancers. These elements are hardened against attack according to industry and ISC best practices. They are managed by expert certified network administrators. Configuration data is replicated and archived centrally. Changes are logged per user. Remote administration of the network elements is done by a limited set of authorized staff, using secure channels with limited points of network ingress. Only ISC employees or carefully-vetted contractors can have any form of access (physical or administrative) to Registry systems. In case of emergency, police and fire officers may be permitted access, duly documented and monitored by the data center staff.
In addition to securing the network elements themselves, dedicated or embedded firewalling capabilities are used to ensure that only authorized and appropriate network traffic reaches the registry systems. Should elevated or atypical network traffic be detected, appropriate notifications will be made to the monitoring system. Every system is monitored, and all monitoring data is centrally gathered and logged.
30(a).1.4. Service Security
Access to the SRS service is permitted only to those registrars that have current signed agreements with the TLD operator. Registrars will provide a list of IP addresses to be permitted to connect to the EPP servers. No connections are permitted from unauthorized client addresses. In addition the system uses SSL-based certificates to establish secure TCP connections, allowing the client and the server to authenticate one another, before supplying a mandatory user⁄password combination to authenticate an EPP session.
Services that are exposed to the Internet such as Whois, and DNS, are designed and deployed with secure techniques that prevent data from unauthorized alteration.
Tiered access services, such as the RESTful Whois interface, use SSL encryption for transmission of all sensitive information, such as passwords, or privileged information.
30(a).1.5. Data Security
While the DNS zones created by the registry from registrantsʹ submissions are publicly visible data, a need might evolve to keep some data private. Our system is ready for this eventuality. All data (whether private or not) is secured during network communication by end to end encryption. The integrity of public DNS data is ensured through the use of cryptographic shared secrets for all internal transfers. Once on the servers, regular backups are made to ensure no data is lost, and copies of backups are replicated to geographically distant data centers. Backups are encrypted, and copies of those encrypted backups will be in secure locations.
30(a).1.6. Security Monitoring
Despite security-oriented design and hardening, it is inevitable that any service provided on the Internet will receive unwanted traffic. It is critical that the SNS and Registry systems be able to detect anomalous traffic, and to correlate events across multiple elements to alert operators and provide key data to differentiate between increased benign traffic and a true attack. The SNS and Registry systems perform this functionality via centralized logging and analysis, detection of anomalous traffic by the network elements, and application-specific alerts. Additionally, all servers are regularly scanned for unauthorized code, and the entire system is periodically swept with network scans. The Registry Operations Center is responsible for determining the frequency of such scans and sweeps, but never less frequent than once per calendar quarter.
All security information is received by, and distributed by (as needed), the help desk⁄call center and the Registry Operations Center. Any distribution of security-related information outside Uniregistry must be via Uniregistry corporate management and not by any operations personnel except with explicit per-case specific approval by corporate management.
30(a).1.7. Attack Mitigation
Industry best practices are used to mitigate the effect of any attack. Such mitigation includes topological containment of the attack (isolating it to some portion of the network) and service continuity using alternate servers or sites.
Significant overprovisioning, load balancing, and firewalls are used to dilute, divert, and deflect the force of brute force attacks. Anycast routing limits the scope of attacks on our name server infrastructure.
30(a).1.8. Personnel Policies
Registry operations personnel are all subject to background checks.
Job duties are arranged, and supported by data⁄system access constraints, so that no person has more access than is needed for the performance of their job duties.
We will have an employee handbook that will define employee duties and obligations. Employees will have to assent, in writing, to that handbook at least once a year.
Consultants, contractors, and other third parties will be required to enter into an appropriate Non Disclosure Agreement that will define their duties and limitations.
30(a).1.9. Security Incident Response
Should a Security Event be detected or reported, the Registry System Security Response Plan will be triggered. This plan defines formal roles for staff, a process for technical analysis of the event, proper communications procedures and event resolution.
30(A).2. INDEPENDENT ASSESSMENT ON SECURITY CONTROLS
Uniregistry has built its platform, policies and procedures following industry best practices and sound commercial guidelines to ensure the highest levels of commercially reasonable security. This encompasses as a minimum: Physical Security, System Security, Network Security, Service Security and Data Security. The fact that Uniregistry is beginning as a registry operator with a clean slate allows for the application of best-practice policies and controls from day one.
That said (and regardless of the level of preparedness shown in the design and implementation of our policies and security controls), it is impossible for any newly formed entity beginning its duties as a registry operator to present an effective, meaningful and Independent Assessment of the effectiveness of security controls; as this is an area that needs to be evaluated on a day to day basis - based on operations which in Uniregistryʹs case, have not yet begun.
30(A).3. ABOUT THIS RESPONSE
This answer is extended in our answer to question 30b.
Similar gTLD applications: (57)
|gTLD||Full Legal Name||E-mail suffix||z||Detail|
|.locus||Locus Analytics LLC||tyemill.com||-3.62||Compare|
|.MOSCOW||Foundation for Assistance for Internet Technologies and Infrastructure Development (FAITID)||sedari.com||-3.62||Compare|
|.москва||Foundation for Assistance for Internet Technologies and Infrastructure Development (FAITID)||sedari.com||-3.61||Compare|