Back

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

gTLDFull Legal NameE-mail suffixDetail
.tciAsia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.nsline.comView
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. and CoCCA desire to ensure the highest levels of security are applied and maintained for all elements in the chain that ultimately result in the resolution of a .tci TLD on the Internet. CoCCA, together with partners PCH and ISC will endeavor to ensure the secure operation of Registry Services for the .tci TLD as described below.

30.1 DNSSEC - Facility for Key Storage
For reasons of economies of scale and because CoCCA has a nearly decade long relationship with PCH, the .tci key is to be stored offline at a Singapore facility hosted by the National University of Singapore, on behalf of the Singaporean Infocomm Development Agency (IDA), other DNSSEC key-store facilities that are part of PCHʹs project are hosted in Zurich by SWITCH, the Swiss national research and education network and at a U.S. facility hosted by Equinix in San Jose California. The PCH DNSSEC project facilities mirror the security and processes used by ICANN for maintenance of the root.

See Attachment PCH_SG_Backgrounder.pdf

30.1.1 Signature of the .tci

The .tci zones generated by the CoCCA SRS will include the DS records submitted by registrars, zones will be transferred from CoCCA’s hidden signing master DNS to four PCH inbound masters using AXFER ⁄ IXFER and TSIG. PCH will transfer the zones using IXFR ⁄ AXFRE and TSIG to their signer servers in Frankfurt and Palo Alto. The signed zone is then exported to PCH’s two outbound DNSSEC DNS for secure ASXFR ⁄ IXFR TSIG transfer back to CoCCA’s inbound DNSSEC master in Sydney. Key signing keys and zone signing keys are to be rolled out in accordance with best practices and ICANN requirements. CoCCA and PCHʹs DNSSEC implementation fully adheres to applicable RFCʹs and to the requirements of Specification 6, section 1.3.

30.1.2 Secure Distribution of the Signed Zones

CoCCA has employed the use of a double Anycast and Unicast network for the purpose of distributing signed zones across the DNS. Due to CoCCA’s desire to ensure that this process is not compromised, CoCCA logs and monitors the zone signing and distribution process, and also ensures that the management of signed zones is performed by CoCCA.

On receipt of the signed zones from PCH, CoCCA will perform some basic validation against the zones sent to PCH, and then transfer these zones onto a hidden distribution master DNS which will transfer zones via TSIG and IXAFR⁄ AXFR to ISCʹs SNC platform, PCHʹs Anycast platform and CoCCA’s Unicast DNS servers. If a critical issue was found that was impacting both the primary and secondary SRS, and if instructed by CoCCA, PCH may distribute the zones to their own Anycast network, the ISC SNS Anycast network and the CoCCA Unicast nodes.

The procedures above have been tested by ccTLDs on CoCCA’s SRS platform.

30.2 Securing the .tci DNS infrastructure and Nodes

The .tci TLD will rely on ISC’s and PCH’s Anycast networks and CoCCA’s Unicast for resolution. ISC authors BIND and pioneered the use of DNSSEC and Anycast technology, PCH manages what is arguably the largest, most geographically dispersed Anycast network, CoCCA currently operates Unicast TLD servers for 12 TLDs. All three entities utilize best of class technology and have rigorous security policies in place to secure, monitor and respond to threats that may compromise the resolution of the .tci TLD.

Both PCH and ISC are members of NSP-Sec and have BGP sinkhole capabilities. Both organizations are well positioned and able to coordinate with ISPs that may be transiting or sourcing Denial of Service attacks (DoS) or other attack traffic to mitigate it closer to its source. The geographically diverse PCH and ISC Anycast services are extremely resilient against DoS attacks, if a node fails or is otherwise compromised, it will swiftly be taken out of the PCH or ISC Anycast cloud, causing traffic to flow to other nodes with minimal or no service disruption. The two independently operated and managed Anycast networkʹs total distributed capacity will allow the .tci to absorb even a coordinated DoS attack originating from multiple locations at once.

The geographically diverse Anycast network proposed for .tci necessitates locating dozens of nodes in a variety of co-location facilities varying from Tier 4 to Tier 2 - and each facility has different security policies for physical access. From a security and stability perspective, the critical issue is that all nodes be monitored in real time by PCH, ISC and CoCCA and any node that experiences SLA issues (or is otherwise compromised) is swiftly taken offline or out of the Anycast network. Under CoCCAʹs agreements with PCH and ISC, any SLA or security issues with any node in their respective Anycast networks is to be reported immediately so that CoCCA may advise registrars or take any other appropriate action.

30.3 CoCCA’s Sydney SRS Security Policy

30.3.1 CoCCA SYD NOC | SRS Physical Access
CoCCA’s primary NOC is located at Global Switch in the Sydney CBD, an enhanced Tier-3 facility and one of the largest carrier neutral data centers in the southern hemisphere. CoCCA’s SRS servers are housed in a dedicated, caged rack provided by PIPE networks, PIPE also provides CoCCA with the primary bandwidth used by the Sydney SRS.

In order to gain physical access to CoCCA’s servers, an individual must be pre-authorised by CoCCA, pipe and Global Switch - and have formally been inducted by Global Switch. Once approved to enter the facility, an individual must be inspected and be granted access by the Global Switch Security Operations Centre - which is manned 24x7 by security personnel. After passing security, physical access requires passing through a mantrap. Access to the floor, pipe co-location room and master cage is controlled by key-cards with strict access control lists.

Access to CoCCA’s cage and rack require a combination of key-cards and physical keys both of which are distributed by, and only available to, CoCCA staff. All spaces are under constant CCTV surveillance by global switch security and the PIPE Network’s NOC.

CoCCA’s policy is to severely restrict physical access to network appliances, currently only six individuals have physical access to the CoCCA SRS in Sydney and all access is logged. CoCCA’s security policy for physical access is collateral to the Global Switch and PIPE Networks.

30.3.2 CoCCA SYD NOC | SRS Admin Remote Access

The number of individuals with the ability to directly access and administer network appliances is very small - currently six, a number not expected to grow with additional gTLDs. Remote access is only accessible through VPN with the mandatory requirement to use one time passwords (OTP) for authentication purposes. SRS server command line logins use both OTP as well as traditional username and password authentication methods - enabling each login to be traced to an individual.

CoCCA NOC Support Staff, Registrar Support and Complaint ⁄ Abuse Officers and Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. staff may only access the SRS via port 443 with OTP from trusted IP addresses. CoCCA NOC Support Staff, Registrar Support and Complaint ⁄ Abuse Officers and Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. staff have no physical or remote administrative access to servers or network appliances.

30.3.3 CoCCA’s ʺpamojaʺ SRS Software Testing

In designing any security regime it is important to clearly identity potential threats and design the policy to address them. The SRS data is a compilation of publicly available data, and all information on Registrants, Registrars, and Resellers is available via WHOIS, RDDS services or Historical Abstracts. CoCCA does not store credit card or other commercially sensitive confidential information on registrants or registrars in the SRS (or elsewhere). The security threat is not theft of SRS data, it is loss of data or tampering with data.

Information relating to the management of the Data Escrow processes performed by NCC and CoCCA Data Escrow (NZ) Limited, including information in relation to the backup policies are explained in response to question 38. The Data Escrow process ensures that data is protected against security breaches that result in the loss or unauthorized modification of SRS data, especially as the data can be recovered from several sources. The CoCCA security policy is designed to protect against un-authorized modification of production SRS data.

The only information stored in the SRS that could present a risk should the entire SRS be compromised, stolen and released ʺinto the wildʺ are SRS credentials and AuthCodes. The credentials and AuthCodes are Hashed (MD5) and Encrypted in the DB. GUI access to CoCCAʹs production systems is only granted from trusted IPʹs with a requirement for OTP use. For EPP access to the production SRS, the registrarʹs IP must be white-listed and they must connect with a CoCCA issued SSL certificate. Even if one were able to steal the SRS DB and de-crypt the login credentials or AuthCodes, other security measures such as IP address locking, OTP and CoCCA issued certificates ensure potential data thieves would not be able to use them to access CoCCAʹs production SRS or modify data.

Securing the SRS largely requires ensuring the SRS software cannot be exploited by users. The SRS has four public facing websites, the WHOIS, RDDS, Historical Abstracts and Key Retrieval. The GUI login is not public facing.

CoCCA uses the same ʺpamojaʺ SRS database application that it distributes to over 20+ other TLD managers. While the application is tested internally by CoCCA and other TLD manager’s, developers and systems administrators, CoCCA has a policy that each major release also be tested by an independent software testing laboratory. Currently we have contracted with Yonita (http:⁄⁄yonita.com). Yonita tests ⁄ audits the pamoja SRS application (not CoCCAʹs NOC) for:

* Security vulnerabilities
* Standard quality defects
* Performance anti-patterns
* Database and transaction misuses
* Concurrency issues
* Architectural bad practices

30.3.4 Monitoring and Detecting Threats

CoCCA monitors network traffic and activity through automated processes and seeks to detect threats that impact the SRS and more broadly CoCCA’s Registry Services.

PCH and ISC directly monitor and attempt to detect threats that impact the DNSSEC signing and storage facilities as well as PCHʹs and ISCʹs respective Anycast networks. Any incident that impacts the security and stability of the .tci TLD in either the PCH DNSSEC facilities or nodes on the ISC or PCH Anycast networks is logged and reported to the CoCCA NOC immediately. ISC and PCH have near-real time reporting for all the Anycast nodes in their clouds and make this information available to CoCCA.

30.3.5 CoCCA SRS NOC | Essential Services Policy

CoCCA’s Security Policy mandates that only essential SRS services (production EPP, WHOIS, RDDS, and SRS GUI with limited access) are to be hosted at the Sydney NOC.

Public facing policy websites, email servers, help-desk software, svn, GIT, team sites, OTE environments, and software development servers are all hosted externally using various commercial cloud - based services. None of these cloud-based servers are configured in such a way that they have access to any SRS services that are not normally available to the public.

30.3.6 CoCCA SRS NOC | Public Access Restrictions Policy

CoCCA’s security policy dictates that only the port 43 WHOIS server, port 443 web-based WHOIS, port 443 AuthCode retrieval site, and port 443 Historical Abstract Site and a single unicast DNS server for the .tci TLD are to be publicly accessible.

Registrars, CoCCA’s registrar support staff, law enforcement or CERTs may access the port 443 GUI interface only if their IP addresses have been white listed in advance and they authenticate using clientID, login and an OTP. CoCCA’s use of OTP tokens allows CoCCA to track activity in the SRS by individual not just loginID (username).
30.3.7 CoCCA SRS NOC | Intrusion Detection

CoCCA Security Policy requires that all SRS traffic originating from outside the NOC be subjected to automated intrusion detection. CoCCA’s firewalls (Watchgaurd XTM) are configured for intrusion detection and are able to inspect encrypted HTTPS traffic. CoCCA’s Barracuda load balancers provide an additional layer of firewall protection, DoS and automated intrusion detection. CoCCAʹs NOC firewalls are configured in accordance with best practices with both port and application layer filtering. The load balancers are configured for NAT and are also configured for intrusion detection and DoS attacks.

30.3.8 CoCCA SRS NOC | Auditing an Logging

CoCCA’s Security Policy requires that all access to the SRS via the port 443 GUI is logged with originating IP, clientID, OTP (generated by security token), and that the sessions are time and date stamped. All EPP and WHIOS access logs are to be stored for seven days in the production SRS where they can be readily accessed before being archived. Firewall and VPN access is also logged.

30.3.9 CoCCA SRS NOC | Incident Response

CoCCA NOC Support staff are on hand 24⁄7⁄365 to monitor the Registry Services offered at the primary SRS in Sydney and the availability of the Failover and Escrow SRS facilities. NOC Staff perform three ʺrolesʺ:

1) monitoring the CoCCA Sydney NOC and failover SRSʹs - and a dozen or so other SRS’s that CoCCA supports;
2) registrar support for the CoCCA NOC and four other locally hosted ccTLDs; and
3) serve as front-line Complaint Resolution Service Officers able to trigger a CoCCA Critical Issue Suspension (CIS) or Uniform Rapid Suspension on a 24⁄7⁄365 basis.

The level of SRS access and skills required to perform all three roles are similar. CoCCA NOC support staff have no VPN access or other access to appliances at the CoCCA SRS. The GUI access they have is limited to Customer Service functions, and all the applications they use (helpdesk, monitoring, accounting, email) are hosted outside the primary NOC.

CoCCAʹs NOC support is a virtual ʺfunctionʺ performed by individuals in New Zealand, Guyana and France (additional NOC staff will be trained and other centers incorporated into the service in Q4 2012). If there is a failure in any of CoCCA’s Registry Services functions, the role of the NOC Support is to:

1) raise the alarm with CoCCA systems administrators or developers as conditions and events dictate;
2) liaise with PIPE Networks, PCH, ISC, IANA ⁄ ICANN and registrars as required.

30.3.10 Provisioning against DNS Denial of Service attacks

A Denial of Service (DoS) attack on a network service floods it with fraudulent requests so that there is no capacity left for legitimate requests. CoCCAʹs Anycast DNS service is outsourced to PCH and ISCʹs Anycast networks, CoCCA’s managed Unicast DNS ensures Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. has at least two ʺlast resortʺ DNS nodes under direct management. Both PCH and ISC networks provide the .tci with substantial protection against DoS attacks, including Anycasting, over provisioning, and network traffic shaping.

Both PCH and ISC utilize traffic shaping methods that rate limit the number of queries per IP address to help prevent abuse and to trigger an investigation of elevated traffic levels to see whether an attacker is testing resource limits or whether ISC or PCH should provision additional bandwidth⁄servers or remove the node temporarily. In cases of an active DoS against ISC, CoCCA or PCH each will make every effort to identify the offending traffic and its sources to squelch offending traffic at ISP borders before reaching the servers as well as augmenting capacity to handle any legitimate elevated traffic levels.

30.3.11 Provisioning against WHOIS and EPP Denial of Service attacks

CoCCA actively monitors all Registry Services to ensure they meet any required SLA. In the event of a DoS attack that threatens to lower the SLA for WHOIS or EPP services required in the ICANN Agreement, CoCCA will work with our upstream providers (who also monitor the traffic) and attempt to squelch offending traffic at the ISP borders before it reaches the CoCCA RDDS servers. In the event the traffic is found to be legitimate, the bandwidth can be swiftly increased as required.

30.3.12 Failover Routing

CoCCA currently has multiple links to the Internet but does not load balance across them all. The secondary (failover) link is used to replicate and transfer backup WAL and VM image data files to CoCCAʹs Failover SRS infrastructure (currently located in Palo Alto) and Escrow NOC. If there is a critical infrastructure issue at PIPE Networks, BGP routing will be used to move our critical infrastructure on our IPV4 and IPV6 address blocks to the failover Telstra link or to one of the two SRS instances outside of Australia. A forth node will be added in Paris (France) in early 2013.

If the issue relates to an SLA problem, changing the A record and CNAME for RDDS services may be sufficient to resolve such an issue in a timely manner. If required by a pro-longed outage BGP routing may be used to re-rout the entire ranges to a failover facility.

30.3.13 Commitments to Registrants

Taken from the .tci WHOIS and Privacy Policy

ʺ6. DATA SECURITY

6.1 CoCCA shall take reasonable steps to protect the Personal Information it holds from misuse and loss and from unauthorized access, modification or disclosure.

7. OPENNESS
7.1 This Policy sets out CoCCAʹs policies on its management of Personal Information. CoCCA shall make this document available to anyone who asks for it.

7.2 On request by any person, CoCCA shall take reasonable steps to let the person know, generally, what sort of Personal Information CoCCA holds, for what purposes, and how it collects, holds, uses and discloses that information.

8. ACCESS AND CORRECTION
8.1 All Registrant information lodged by a registrar that is maintained in the CoCCA SRS is publicly available from CoCCAʹs RDDS services - WHOIS, Premium WHOIS, and Historical Abstracts.

See the .tci RDDS Policy (Attached) for more information.

8.2 If CoCCA holds Personal Information about a Registrant and the Registrant is able to establish that the information is not true, accurate, and complete and⁄or up-to-date, CoCCA shall take reasonable steps to facilitate corrections to the information so that current information is accurate, complete and up-to-date - except where the data is contained in an historical record or archive.ʺ

30.3.14 Independent Security Assessments

In addition to software and source security Audits, CoCCA has engaged the services of Connell Wagner Pty Ltd (now known as Aurecon Group Brand (Pte) Ltd) for the purpose of performing independent security audits of the primary data center.

On the condition that a gTLD is approved, CoCCA will engage the services of Aurecon to perform independent security audits to ensure the CoCCA system fully complies with all published security requirements set forth by ICANN. Such reports will be provided to ICANN on request. With new IT infrastructure planned for deployment in 2012 and early 2013, CoCCA will contract further independent assessments with third parties.
gTLDFull Legal NameE-mail suffixDetail
.wedAtgron, Inc.atgron.comView
30a Security Policy
Atgron and CoCCA desire to ensure the highest levels of security are applied and maintained for all elements in the chain that ultimately result in the resolution of the .WED TLD on the Internet. CoCCA, together with partners PCH and ISC will endeavor to ensure the secure operation of Registry Services for the .WED TLD as described below.

30.1 DNSSEC - Facility for Key Storage
For reasons of economies of scale and because CoCCA has a nearly decade long relationship with PCH, the .WED key is to be stored offline at a Singapore facility hosted by the National University of Singapore, on behalf of the Singaporean Infocomm Development Agency (IDA), other DNSSEC key-store facilities that are part of PCHʹs project are hosted in Zurich by SWITCH, the Swiss national research and education network and at a U.S. facility hosted by Equinix in San Jose California. The PCH DNSSEC project facilities mirror the security and processes used by ICANN for maintenance of the root.

See Attachment PCH_SG_Backgrounder.pdf

30.1.1 Signature of the .WED TLD

The .WED zones generated by the CoCCA SRS will include the DS records submitted by registrars, zones will be transferred from CoCCAʹs hidden signing master DNS to four PCH inbound masters using AXFER ⁄ IXFER and TSIG. PCH will transfer the zones using IXFR ⁄ AXFRE and TSIG to their signer servers in Frankfurt and Palo Alto. The signed zone is then exported to PCHʹs two outbound DNSSEC DNS for secure ASXFR ⁄ IXFR TSIG transfer back to CoCCAʹs inbound DNSSEC master in Sydney. Key signing keys and zone signing keys are to be rolled out in accordance with best practices and ICANN requirements. CoCCA and PCHʹs DNSSEC implementation fully adheres to applicable RFCʹs and to the requirements of Specification 6, section 1.3.

30.1.2 Secure Distribution of the Signed Zones

CoCCA has employed the use of a double Anycast and Unicast network for the purpose of distributing signed zones across the DNS. Due to CoCCAʹs desire to ensure that this process is not compromised, CoCCA logs and monitors the zone signing and distribution process, and also ensures that the management of signed zones is performed by CoCCA.

On receipt of the signed zones from PCH, CoCCA will perform some basic validation against the zones sent to PCH, and then transfer these zones onto a hidden distribution master DNS which will transfer zones via TSIG and IXAFR⁄ AXFR to ISCʹs SNC platform, PCHʹs Anycast platform and CoCCAʹs Unicast DNS servers. If a critical issue was found that was impacting both the primary and secondary SRS, and if instructed by CoCCA, PCH may distribute the zones to their own Anycast network, the ISC SNS Anycast network and the CoCCA Unicast nodes.

The procedures above have been tested by ccTLDs on CoCCAʹs SRS platform.

30.2 Securing the .WED DNS infrastructure and Nodes

The .WED TLD will rely on ISCʹs and PCHʹs Anycast networks and CoCCAʹs Unicast for resolution. ISC authors BIND and pioneered the use of DNSSEC and Anycast technology, PCH manages what is arguably the largest, most geographically dispersed Anycast network, CoCCA currently operates Unicast TLD servers for 12 TLDs. All three entities utilize best of class technology and have rigorous security policies in place to secure, monitor and respond to threats that may compromise the resolution of the .WED TLD.

Both PCH and ISC are members of NSP-Sec and have BGP sinkhole capabilities. Both organizations are well positioned and able to coordinate with ISPs that may be transiting or sourcing Denial of Service attacks (DoS) or other attack traffic to mitigate it closer to its source. The geographically diverse PCH and ISC Anycast services are extremely resilient against DoS attacks, if a node fails or is otherwise compromised, it will swiftly be taken out of the PCH or ISC Anycast cloud, causing traffic to flow to other nodes with minimal or no service disruption. The two independently operated and managed Anycast networkʹs total distributed capacity will allow the .WED TLD to absorb even a coordinated DoS attack originating from multiple locations at once.

The geographically diverse Anycast network proposed for .WED necessitates locating dozens of nodes in a variety of co-location facilities varying from Tier 4 to Tier 2 - and each facility has different security policies for physical access. From a security and stability perspective, the critical issue is that all nodes be monitored in real time by PCH, ISC and CoCCA and any node that experiences SLA issues (or is otherwise compromised) is swiftly taken offline or out of the Anycast network. Under CoCCAʹs agreements with PCH and ISC, any SLA or security issues with any node in their respective Anycast networks is to be reported immediately so that CoCCA may advise registrars or take any other appropriate action.

30.3 CoCCAʹs Sydney SRS Security Policy

30.3.1 CoCCA SYD NOC | SRS Physical Access
CoCCAʹs primary NOC is located at Global Switch in the Sydney CBD, an enhanced Tier-3 facility and one of the largest carrier neutral data centers in the southern hemisphere. CoCCAʹs SRS servers are housed in a dedicated, caged rack provided by PIPE networks, PIPE also provides CoCCA with the primary bandwidth used by the Sydney SRS.

In order to gain physical access to CoCCAʹs servers, an individual must be pre-authorised by CoCCA, PIPE and Global Switch - and have formally been inducted by Global Switch. Once approved to enter the facility, an individual must be inspected and be granted access by the Global Switch Security Operations Centre - which is manned 24x7 by security personnel. After passing security, physical access requires passing through a mantrap. Access to the floor, PIPE co-location room and master cage is controlled by key-cards with strict access control lists.

Access to CoCCAʹs cage and rack require a combination of key-cards and physical keys both of which are distributed by, and only available to, CoCCA staff. All spaces are under constant CCTV surveillance by Global Switch security and the PIPE Networkʹs NOC.

CoCCAʹs policy is to severely restrict physical access to network appliances, currently only six individuals have physical access to the CoCCA SRS in Sydney and all access is logged. CoCCAʹs security policy for physical access is collateral to that of Global Switch and PIPE Networks.

30.3.2 CoCCA SYD NOC | SRS Admin Remote Access

The number of individuals with the ability to directly access and administer network appliances is very small - currently six, a number not expected to grow with additional gTLDs. Remote access is only accessible through VPN with the mandatory requirement to use one time passwords (OTP) for authentication purposes. SRS server command line logins use both OTP as well as traditional username and password authentication methods - enabling each login to be traced to an individual.

CoCCA NOC Support Staff, Registrar Support and Complaint ⁄ Abuse Officers and Atgron staff may only access the SRS via port 443 with OTP from trusted IP addresses. CoCCA NOC Support Staff, Registrar Support and Complaint ⁄ Abuse Officers and Atgron staff have no physical or remote administrative access to servers or network appliances.

30.3.3 CoCCAʹs ʺpamojaʺ SRS Software Testing

In designing any security regime it is important to clearly identity potential threats and design the policy to address them. The SRS data is a compilation of publicly available data, and all information on Registrants, Registrars, and Resellers is available via WHOIS, RDDS services or Historical Abstracts. CoCCA does not store credit card or other commercially sensitive confidential information on registrants or registrars in the SRS (or elsewhere). The security threat is not theft of SRS data, it is loss of data or tampering with data.

Information relating to the management of the Data Escrow processes performed by NCC and CoCCA Data Escrow (NZ) Limited, including information in relation to the backup policies are explained in response to question 38. The Data Escrow process ensures that data is protected against security breaches that result in the loss or unauthorized modification of SRS data, especially as the data can be recovered from several sources. The CoCCA security policy is designed to protect against un-authorized modification of production SRS data.

The only information stored in the SRS that could present a risk should the entire SRS be compromised, stolen and released ʺinto the wildʺ are SRS credentials and AuthCodes. The credentials and AuthCodes are Hashed (MD5) and Encrypted in the DB. GUI access to CoCCAʹs production systems is only granted from trusted IPʹs with a requirement for OTP use. For EPP access to the production SRS, the registrarʹs IP must be white-listed and they must connect with a CoCCA issued SSL certificate. Even if one were able to steal the SRS DB and de-crypt the login credentials or AuthCodes, other security measures such as IP address locking, OTP and CoCCA issued certificates ensure potential data thieves would not be able to use them to access CoCCAʹs production SRS or modify data.

Securing the SRS largely requires ensuring the SRS software cannot be exploited by users. The SRS has four public facing websites, the WHOIS, RDDS, Historical Abstracts and Key Retrieval. The GUI login is not public facing.

CoCCA uses the same ʺpamojaʺ SRS database application that it distributes to over 20+ other TLD managers. While the application is tested internally by CoCCA and other TLD managerʹs, developers and systems administrators, CoCCA has a policy that each major release also be tested by an independent software testing laboratory. Currently we have contracted with Yonita (http:⁄⁄yonita.com). Yonita tests ⁄ audits the pamoja SRS application (not CoCCAʹs NOC) for:

* Security vulnerabilities
* Standard quality defects
* Performance anti-patterns
* Database and transaction misuses
* Concurrency issues
* Architectural bad practices

30.3.4 Monitoring and Detecting Threats

CoCCA monitors network traffic and activity through automated processes and seeks to detect threats that impact the SRS and more broadly CoCCAʹs Registry Services.

PCH and ISC directly monitor and attempt to detect threats that impact the DNSSEC signing and storage facilities as well as PCHʹs and ISCʹs respective Anycast networks. Any incident that impacts the security and stability of the .WED TLD in either the PCH DNSSEC facilities or nodes on the ISC or PCH Anycast networks is logged and reported to the CoCCA NOC immediately. ISC and PCH have near-real time reporting for all the Anycast nodes in their clouds and make this information available to CoCCA.

30.3.5 CoCCA SRS NOC | Essential Services Policy

CoCCAʹs Security Policy mandates that only essential SRS services (production EPP, WHOIS, RDDS, and SRS GUI with limited access) are to be hosted at the Sydney NOC.

Public facing policy websites, email servers, help-desk software, svn, GIT, team sites, OTE environments, and software development servers are all hosted externally using various commercial cloud - based services. None of these cloud-based servers are configured in such a way that they have access to any SRS services that are not normally available to the public.

30.3.6 CoCCA SRS NOC | Public Access Restrictions Policy

CoCCAʹs security policy dictates that only the port 43 WHOIS server, port 443 web-based WHOIS, port 443 AuthCode retrieval site, and port 443 Historical Abstract Site and a single unicast DNS server for the .WED TLD are to be publicly accessible.

Registrars, CoCCAʹs registrar support staff, law enforcement or CERTs may access the port 443 GUI interface only if their IP addresses have been white listed in advance and they authenticate using clientID, login and an OTP. CoCCAʹs use of OTP tokens allows CoCCA to track activity in the SRS by individual not just loginID (username).
30.3.7 CoCCA SRS NOC | Intrusion Detection

CoCCA Security Policy requires that all SRS traffic originating from outside the NOC be subjected to automated intrusion detection. CoCCAʹs firewalls (Watchgaurd XTM) are configured for intrusion detection and are able to inspect encrypted HTTPS traffic. CoCCAʹs Barracuda load balancers provide an additional layer of firewall protection, DoS and automated intrusion detection. CoCCAʹs NOC firewalls are configured in accordance with best practices with both port and application layer filtering. The load balancers are configured for NAT and are also configured for intrusion detection and DoS attacks.

30.3.8 CoCCA SRS NOC | Auditing an Logging

CoCCAʹs Security Policy requires that all access to the SRS via the port 443 GUI is logged with originating IP, clientID, OTP (generated by security token), and that the sessions are time and date stamped. All EPP and WHIOS access logs are to be stored for seven days in the production SRS where they can be readily accessed before being archived. Firewall and VPN access is also logged.

30.3.9 CoCCA SRS NOC | Incident Response

CoCCA NOC Support staff are on hand 24⁄7⁄365 to monitor the Registry Services offered at the primary SRS in Sydney and the availability of the Failover and Escrow SRS facilities. NOC Staff perform three ʺrolesʺ:

1) monitoring the CoCCA Sydney NOC and failover SRSʹs - and a dozen or so other SRSʹs that CoCCA supports;
2) registrar support for the CoCCA NOC and four other locally hosted ccTLDs; and
3) serve as front-line Complaint Resolution Service Officers able to trigger a CoCCA Critical Issue Suspension (CIS) or Uniform Rapid Suspension on a 24⁄7⁄365 basis.

The level of SRS access and skills required to perform all three roles are similar. CoCCA NOC support staff have no VPN access or other access to appliances at the CoCCA SRS. The GUI access they have is limited to Customer Service functions, and all the applications they use (helpdesk, monitoring, accounting, email) are hosted outside the primary NOC.

CoCCAʹs NOC support is a virtual ʺfunctionʺ performed by individuals in New Zealand, Guyana and France (additional NOC staff will be trained and other centers incorporated into the service in Q4 2012). If there is a failure in any of CoCCAʹs Registry Services functions, the role of the NOC Support is to:

1) raise the alarm with CoCCA systems administrators or developers as conditions and events dictate;
2) liaise with PIPE Networks, PCH, ISC, IANA ⁄ ICANN and registrars as required.

30.3.10 Provisioning against DNS Denial of Service attacks

A Denial of Service (DoS) attack on a network service floods it with fraudulent requests so that there is no capacity left for legitimate requests. CoCCAʹs Anycast DNS service is outsourced to PCH and ISCʹs Anycast networks, CoCCAʹs managed Unicast DNS ensures Atgron has at least two ʺlast resortʺ DNS nodes under direct management. Both PCH and ISC networks provide the .WED TLD with substantial protection against DoS attacks, including Anycasting, over provisioning, and network traffic shaping.

Both PCH and ISC utilize traffic shaping methods that rate limit the number of queries per IP address to help prevent abuse and to trigger an investigation of elevated traffic levels to see whether an attacker is testing resource limits or whether ISC or PCH should provision additional bandwidth⁄servers or remove the node temporarily. In cases of an active DoS against ISC, CoCCA or PCH, each will make every effort to identify the offending traffic and its sources to squelch offending traffic at ISP borders before it reachs the servers and to augment capacity to handle any legitimate elevated traffic levels.

30.3.11 Provisioning against WHOIS and EPP Denial of Service attacks

CoCCA actively monitors all Registry Services to ensure they meet any required SLA. In the event of a DoS attack that threatens to lower the SLA for WHOIS or EPP services required in the ICANN Agreement, CoCCA will work with our upstream providers (who also monitor the traffic) and attempt to squelch offending traffic at the ISP borders before it reaches the CoCCA RDDS servers. In the event the traffic is found to be legitimate, the bandwidth can be swiftly increased as required.

30.3.12 Failover Routing

CoCCA currently has multiple links to the Internet but does not load balance across them all. The secondary (failover) link is used to replicate and transfer backup WAL and VM image data files to CoCCAʹs Failover SRS infrastructure (currently located in Palo Alto) and Escrow NOC. If there is a critical infrastructure issue at PIPE Networks, BGP routing will be used to move our critical infrastructure on our IPV4 and IPV6 address blocks to the failover Telstra link or to one of the two SRS instances outside of Australia. A forth node will be added in Paris (France) in early 2013.

If the issue relates to an SLA problem, changing the A record and CNAME for RDDS services may be sufficient to resolve such an issue in a timely manner. If required by a pro-longed outage, BGP routing may be used to re-rout the entire ranges to a failover facility.

30.3.13 Commitments to Registrants

Taken from the .WED Privacy and RDDS Policy

ʺ6. DATA SECURITY

6.1 CoCCA shall take reasonable steps to protect the Personal Information it holds from misuse and loss and from unauthorized access, modification or disclosure.

7. OPENNESS
7.1 This Policy sets out CoCCAʹs policies on its management of Personal Information. CoCCA shall make this document available to anyone who asks for it.

7.2 On request by any person, CoCCA shall take reasonable steps to let the person know, generally, what sort of Personal Information CoCCA holds, for what purposes, and how it collects, holds, uses and discloses that information.

8. ACCESS AND CORRECTION
8.1 All Registrant information lodged by a registrar that is maintained in the CoCCA SRS is publicly available from CoCCAʹs RDDS services - WHOIS, Premium WHOIS, and Historical Abstracts.

See the .WED RDDS Policy (Attached) for more information.

8.2 If CoCCA holds Personal Information about a Registrant and the Registrant is able to establish that the information is not true, accurate, and complete and⁄or up-to-date, CoCCA shall take reasonable steps to facilitate corrections to the information so that current information is accurate, complete and up-to-date - except where the data is contained in an historical record or archive.ʺ

30.3.14 Independent Security Assessments

In addition to software and source security Audits, CoCCA has engaged the services of Connell Wagner Pty Ltd (now known as Aurecon Group Brand (Pte) Ltd) for the purpose of performing independent security audits of the primary data center.

On the condition that a gTLD is approved, CoCCA will engage the services of Aurecon to perform independent security audits to ensure the CoCCA system fully complies with all published security requirements set forth by ICANN. Such reports will be provided to ICANN on request. With new IT infrastructure planned for deployment in 2012 and early 2013, CoCCA will contract further independent assessments with third parties.