| gTLD | Full Legal Name | E-mail suffix | Detail | | .saxo | Saxo Bank A⁄S | saxobank.com | View |
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q30a – ARI Background & Roles.pdf’. This response describes Security as implemented by ARI under direction from the registry operator, taking into account any specific needs for this TLD
1 SECURITY POLICY SUMMARY
ARI operates an ISO27001 compliant Information Security Management System (ISMS) for Domain Name Registry Operations; see attachment ‘Q30a – SAI Global Certificate of Compliance.pdf’. The ISMS is an organisation-wide system encompassing all levels of Information Security policy, procedure, standards, and records. Full details of all the policies and procedures included in the ISMS are included in the attachment to Question 30b.
1.1 The ISMS
ARI’s ISMS’s governing policy:
– Defines the scope of operations to be managed (Domain Name Registry Operations).
– Designates the responsible parties (COO, CTO and Information Security Officer) for governance, Production Support Group for implementation and maintenance, and other departments for supporting services.
– Requires a complete Risk Assessment (a developed Security Threat Profile for the Service – in this case registry services for the TLD – and a Risk Analysis tracing threats and vulnerabilities through to Risks) and Risk Treatment Plan (each major risk in the Risk Assessment references the Statement of Applicability indicating controls to be implemented, responsible parties, and the effectiveness metrics for each).
– Includes a series of major sub policies governing security, which include but are not limited to:
– ICT acceptable use policy and physical security policies.
– PSG Security Policy which outlines the registry operations policies, the management of end-user devices, classification of networks and servers according to the classification of information they contain, networking, server & database configuration and maintenance guidelines, vulnerability and patch management, data integrity controls, access management, penetration testing, third party management, logging and monitoring, and cryptography.
– Requires ongoing review:
– Of risks, threats, the Risk Treatment Plan, client requirements and commitments, process and policy compliance, process and policy effectiveness, user etc.
– Regular internal and external penetration testing & vulnerability scanning.
– Ad-hoc review raised during normal operations, common sources being change management processes, scheduled maintenance or project debriefs, and security incidents.
– Yearly review cycle which includes both internal and external audits, including external surveillance audits for compliance.
– Additional yearly security controls assessment reviews, which include analysis of the security control implementations themselves (rather than compliance with any particular standard).
– At 24 month intervals, external penetration testing of selected production services.
– periodic ISO reaccreditation
ARI’s ISMS encompasses the following ARI standards:
– Configuration standards for operating systems, networking devices and databases based on several key publications, including those released by NIST (eg SP800-123, SP800-44v2, SP-800-40, SP800-41) and the NSA, staff testing and experience, and vendor supplied standards.
– Security Incident Classification, which identifies the various classifications of security incidents and events to ensure that events that qualify as security incidents.
– Information Classification and Handling which specifies the information classification scheme and the specific requirements of handling, labelling, management and destruction for each level of classification.
1.2 SECURITY PROCESSES
Processes are used to implement the policies. These include, but are not limited to:
1.2.1 Change Management
This includes change management and its sub-processes for access management, software deployment, release of small changes and scheduled maintenance. This process includes:
– The classification of changes and the flow into sub processes by classification.
– The release and deployment process for change control into production environments, outlining peer review, testing steps, approval points, checklist sets, staging requirements and communication requirements.
– The software release and deployment process with its specific testing and staged rollout requirements.
– The scheduled maintenance process and its various review points.
1.2.2 Incident Management
This includes incident management process and its sub-process for unplanned outages. These outline:
– How incidents are managed through escalation points, recording requirements, communication requirements etc.
– The unplanned outage procedure which applies directly to situations where the registry itself or other critical services are unexpectedly offline.
1.2.3 Problem Management
The goal of problem management is to drive long term resolution of underlying causes of incidents. This process centres on finding and resolving the root causes of incidents. It defines escalation points to third parties or other ARI departments such as Development, as well as verification of the solution prior to problem closure.
1.2.4 Security Incident Management
This process deals with the specific handling of security incidents. It outlines the requirements and decision points for managing security incidents. Decision points, escalation points to senior management and authorities are defined, along with evidence-gathering requirements, classification of incidents and incident logging.
1.2.5 Access Management
This process handles all access changes to systems. HR must authorize new users, and access changes are authorized by departmental managers and approved by the Information Security Officer.
When staff leave or significantly change roles, a separation process is followed which ensures all access that may have been granted during their employment (not just their initially granted access) is checked and where appropriate, revoked.
Finally, quarterly review of all access is undertaken by the ISO, reviewing and approving or rejecting (with an action ticket) as appropriate.
2 ARI’s SECURITY INFRASTRUCTURE SOLUTIONS
ARI has developed a layered approach to IT security infrastructure. At a high level, some of the layers are as follows:
– DDoS countermeasures are employed outside ARI networks. These include routing traps for DDoS attacks, upstream provider intervention, private peering links and third party filtering services.
– Routing controls at the edge of the network at a minimum ensures that only traffic with valid routing passes into ARI networks.
– Overprovisioning and burstable network capabilities help protect against DoS and DDoS attacks.
– Network firewalls filter any traffic not pre-defined by network engineering staff as valid.
– Application layer firewalls then analyse application level traffic and filter any suspicious traffic. Examples of these would be an attempt at SQL injection, script injection, cross-site scripting, or session hijacking.
– Server firewalls on front-end servers again filter out any traffic that is not strictly defined by systems administrators during configuration as valid traffic.
– Only applications strictly necessary for services are running on the servers.
– These applications are kept up-to-date with the latest security patches, as are all of the security infrastructure components that protect them or that they run on.
– ARI infrastructure is penetration-tested by external tools and contracted security professionals for vulnerabilities to known exploits.
– ARI applications are designed, coded and tested to security standards such as OWASP and penetration-tested for vulnerabilities to common classes of exploits by external tools and contracted security professionals.
– ARI configures SELinux on its production servers. Specific details of this configuration is confidential; essentially any compromised application is extremely limited in what it can do.
– Monitoring is used to detect security incidents at all layers of the security model. Specifically:
– Network Intrusion Detection systems are employed to monitor ARI networks for suspicious traffic.
– ARI maintains its own host-based Intrusion Detection system based on tripwire, which has now undergone four years of development. Specific details are confidential, but in summary, the system can detect any unusual activity with respect to configuration, program files, program processes, users, or network traffic.
– More generic monitoring systems are used as indicators of security incidents. Any behaviour outside the norm across over 1,100 individual application, database, systems, network and environmental checks is investigated.
– Capacity management components of the monitoring suite are also used to detect and classify security incidents. Some examples are:
– Network traffic counts, packet counts and specific application query counts.
– Long term trend data on network traffic vs. specific incident windows.
– CPU, Storage, Memory and Process monitors on servers.
– A second layer of hardware firewalling separates application and middle tier servers from database servers.
– Applications only have as much access to database information as is required to perform their function.
– Finally, database servers have their own security standards, including server-based firewalls, vulnerability management for operating system and RDBMS software, and encryption of critical data.
2.1 Physical Security Infrastructure
ARI maintains a series of physical security infrastructure measures including but not limited to biometric and physical key access control to secured areas and security camera recording, alarm systems and monitoring.
3 COMMITMENTS TO REGISTRANTS
We commit to the following:
– Safeguarding the confidentiality, integrity and availability of registrant’s data.
– Compliance with the relevant regulation and legislation with respect to privacy.
– Working with law enforcement where appropriate in response to illegal activity or at the request of law enforcement agencies.
– Maintaining a best practice information security management system that continues to be ISO27001-compliant.
– Validating requests from external parties requesting data or changes to the registry to ensure the identity of these parties and that their request is appropriate. This includes requests from ICANN.
– That access to DNS and contact administrative facilities requires multi-factor authentication by the Registrar on behalf of the registrant.– That Registry data cannot be manipulated in any fashion other than those permitted to authenticated Registrars using the EPP or the SRS web interface. Authenticated Registrars can only access Registry data of domain names sponsored by them.
– A Domain transfer can only be done by utilizing the AUTH CODE provided to the Domain Registrant.
– Those emergency procedures are in place and tested to respond to extraordinary events affecting the integrity, confidentiality or availability of data within the registry.
4 AUGMENTED LEVEL OF SECURITY
This TLD is a SRSU TLD (.brand style) and as such requires security considerations that are commensurate with its purpose. Our goal with this TLD is to use the TLD internally and adequate protect it against unauthorized registrations or modifications to the namespace, without making the internal process too onerous and thus increasing costs. Whilst, due to the SRSU nature, it is relatively straightforward to restrict and enforce restrictions on registrations, the impact of an unauthorised registration can be high, potentially damaging.
The following attributes describe the security with respect to the TLD:
– ARI, follows the highest security standards with respect to its Registry Operations. ARI is ISO 27001 certified and has been in the business of providing a Registry backend for 10 years. ARI have confirmed their adherence to all of the security standards as described in this application. As per recommendation 24 this ensures that the technical implementations do not compromise elevated security standards
– A single Registrar will be nominated for this TLD, facilitating the tightest possible control over Registrant validity enforcement and domain registration restrictions.
– Registrant will only be permitted to make changes to their domain name after a authenticating to their Registrar.
– Registrants will only be able to access all interfaces for domain registration and management via HTTPS. A reputed digital certificate vendor will provide the SSL certificate of the secure site.
– Registrar identity will be manually verified before they are accredited within this TLD. This will include verification of corporate identity, identity of individuals involved ⁄ mentioned, and verification of contact information
– Registrars will only be permitted to connect with the SRS via EPP after a multi-factor authentication that validates their digital identity. This is described further ahead.
– Registrars will only be permitted to use a certificate signed by ARI to connect with the Registry systems. Self-signed certificates will not be permitted.
– The Registry is DNSSEC enabled and the TLD zone will be DNSSEC enabled. This is described in detail in our response to question 43. The following additional requirements will exist for Registrars who want to get accredited to sell this TLD:
– Registrars must support DNSSEC capabilities within its control panels.
– If the Registrar provides Managed DNS services to Registrants within this TLD they must provide DNSSEC for the same. This ensures that DNSSEC is deployed at each zone and subsequent sub-zones at Registry, Registrar and Registrant level as per recommendation 26.
– Registrar access to all Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 27. This is described in detail in our responses to Question 24 and Question 25.
– Registrant access to all Registrar and Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 28. This is described in detail in our response to Question 25, Question 27 and Question 29.
– All communication between the Registrar or the Registrars systems and the registry system is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57. This includes the following communication:
– Secure websites and control panels provided by the Registrar to the Registrant.
– Ticketing systems provided by the Registrar to the Registrant.
– Web and EPP interfaces provided by ARI to the Registrars.
– Ticketing systems provided by ARI to the Registrar.
– Any communication between the Registrant, Registrar and Registry that is deemed as critical or contains credentials or sensitive information.
Where these requirements put controls on Registrars these will be enforced through the RRA.
5 RESOURCES
This function will be performed by ARI. The following resources are allocated to performing the tasks required to deliver the services described:
– Executive Management Team (4 staff)
– Production Support Group (27 staff)
ARI has ten years’ experience designing, developing, deploying, securing and operating critical Registry systems, as well as TLD consulting and technology leadership.
As a technology company, ARI’s senior management are technology and methodology leaders in their respective fields who ensure the organisation maintains a focus on technical excellence and hiring, training and staff management.
Executive Management is heavily involved in ensuring security standards are met and that continued review and improvement is constantly undertaken. This includes the:
– Chief Operations Officer
– Chief Technology Officer
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q30a – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 6000 domains, 0,01% of these resources are allocated to this TLD. See attachment ‘Q30a – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The Production Support Group is responsible for the deployment and operation of TLD registries.
The group consists of:
– Production Support Manager (also the ISO)
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support):
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation:
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrators
– 1 Network Engineers
ARI employs a rigorous hiring process and screening (Police background checks for technical staff and Australian Federal Government ‘Protected’ level security clearances for registry operations staff).
| gTLD | Full Legal Name | E-mail suffix | Detail | | .SCOR | SCOR SE | scor.com | View |
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see attachment ‘Q30(a) – ARI Background & Roles.pdf’. This response describes Security as implemented by ARI under direction from the registry operator, taking into account any specific needs for this TLD.
1 SECURITY POLICY SUMMARY
ARI operates an ISO27001 compliant Information Security Management System (ISMS) for Domain Name Registry Operations; see attachment ‘Q30(a) – SAI Global Certificate of Compliance.pdf’. The ISMS is an organisation-wide system encompassing all levels of Information Security policy, procedure, standards, and records. Full details of all the policies and procedures included in the ISMS are included in the attachment to Question 30(b).
1.1 The ISMS
ARI’s ISMS’s governing policy:
– Defines the scope of operations to be managed (Domain Name Registry Operations).
– Designates the responsible parties (COO, CTO and Information Security Officer) for governance, Production Support Group for implementation and maintenance, and other departments for supporting services.
– Requires a complete Risk Assessment (a developed Security Threat Profile for the Service – in this case registry services for the TLD – and a Risk Analysis tracing threats and vulnerabilities through to Risks) and Risk Treatment Plan (each major risk in the Risk Assessment references the Statement of Applicability indicating controls to be implemented, responsible parties, and the effectiveness metrics for each).
– Includes a series of major sub policies governing security, which include but are not limited to:
– ICT acceptable use policy and physical security policies.
– PSG Security Policy which outlines the registry operations policies, the management of end-user devices, classification of networks and servers according to the classification of information they contain, networking, server and database configuration and maintenance guidelines, vulnerability and patch management, data integrity controls, access management, penetration testing, third party management, logging and monitoring, and cryptography.
– Requires ongoing review:
– Of risks, threats, the Risk Treatment Plan, client requirements and commitments, process and policy compliance, process and policy effectiveness, user etc.
– Regular internal and external penetration testing and vulnerability scanning.
– Ad-hoc review raised during normal operations, common sources being change management processes, scheduled maintenance or project debriefs, and security incidents.
– Yearly review cycle which includes both internal and external audits, including external surveillance audits for compliance.
– Additional yearly security controls assessment reviews, which include analysis of the security control implementations themselves (rather than compliance with any particular standard).
– At 24 month intervals, external penetration testing of selected production services.
– periodic ISO reaccreditation
ARI’s ISMS encompasses the following ARI standards:
– Configuration standards for operating systems, networking devices and databases based on several key publications, including those released by NIST (eg SP800-123, SP800-44v2, SP-800-40, SP800-41) and the NSA, staff testing and experience, and vendor supplied standards.
– Security Incident Classification, which identifies the various classifications of security incidents and events to ensure that events that qualify as security incidents.
– Information Classification and Handling which specifies the information classification scheme and the specific requirements of handling, labelling, management and destruction for each level of classification.
1.2 SECURITY PROCESSES
Processes are used to implement the policies. These include, but are not limited to:
1.2.1 Change Management
This includes change management and its sub-processes for access management, software deployment, release of small changes and scheduled maintenance. This process includes:
– The classification of changes and the flow into sub processes by classification.
– The release and deployment process for change control into production environments, outlining peer review, testing steps, approval points, checklist sets, staging requirements and communication requirements.
– The software release and deployment process with its specific testing and staged rollout requirements.
– The scheduled maintenance process and its various review points.
1.2.2 Incident Management
This includes incident management process and its sub-process for unplanned outages. These outline:
– How incidents are managed through escalation points, recording requirements, communication requirements etc.
– The unplanned outage procedure which applies directly to situations where the registry itself or other critical services are unexpectedly offline.
1.2.3 Problem Management
The goal of problem management is to drive long term resolution of underlying causes of incidents. This process centres on finding and resolving the root causes of incidents. It defines escalation points to third parties or other ARI departments such as Development, as well as verification of the solution prior to problem closure.
1.2.4 Security Incident Management
This process deals with the specific handling of security incidents. It outlines the requirements and decision points for managing security incidents. Decision points, escalation points to senior management and authorities are defined, along with evidence-gathering requirements, classification of incidents and incident logging.
1.2.5 Access Management
This process handles all access changes to systems. HR must authorize new users, and access changes are authorized by departmental managers and approved by the Information Security Officer.
When staff leave or significantly change roles, a separation process is followed which ensures all access that may have been granted during their employment (not just their initially granted access) is checked and where appropriate, revoked.
Finally, quarterly review of all access is undertaken by the ISO, reviewing and approving or rejecting (with an action ticket) as appropriate.
2 ARI’s SECURITY INFRASTRUCTURE SOLUTIONS
ARI has developed a layered approach to IT security infrastructure. At a high level, some of the layers are as follows:
– DDoS countermeasures are employed outside ARI networks. These include routing traps for DDoS attacks, upstream provider intervention, private peering links and third party filtering services.
– Routing controls at the edge of the network at a minimum ensures that only traffic with valid routing passes into ARI networks.
– Overprovisioning and burstable network capabilities help protect against DoS and DDoS attacks.
– Network firewalls filter any traffic not pre-defined by network engineering staff as valid.
– Application layer firewalls then analyse application level traffic and filter any suspicious traffic. Examples of these would be an attempt at SQL injection, script injection, cross-site scripting, or session hijacking.
– Server firewalls on front-end servers again filter out any traffic that is not strictly defined by systems administrators during configuration as valid traffic.
– Only applications strictly necessary for services are running on the servers.
– These applications are kept up-to-date with the latest security patches, as are all of the security infrastructure components that protect them or that they run on.
– ARI infrastructure is penetration-tested by external tools and contracted security professionals for vulnerabilities to known exploits.
– ARI applications are designed, coded and tested to security standards such as OWASP and penetration-tested for vulnerabilities to common classes of exploits by external tools and contracted security professionals.
– ARI configures SELinux on its production servers. Specific details of this configuration is confidential; essentially any compromised application is extremely limited in what it can do.
– Monitoring is used to detect security incidents at all layers of the security model. Specifically:
– Network Intrusion Detection systems are employed to monitor ARI networks for suspicious traffic.
– ARI maintains its own host-based Intrusion Detection system based on tripwire, which has now undergone four years of development. Specific details are confidential, but in summary, the system can detect any unusual activity with respect to configuration, program files, program processes, users, or network traffic.
– More generic monitoring systems are used as indicators of security incidents. Any behaviour outside the norm across over 1,100 individual application, database, systems, network and environmental checks is investigated.
– Capacity management components of the monitoring suite are also used to detect and classify security incidents. Some examples are:
– Network traffic counts, packet counts and specific application query counts.
– Long term trend data on network traffic vs. specific incident windows.
– CPU, Storage, Memory and Process monitors on servers.
– A second layer of hardware firewalling separates application and middle tier servers from database servers.
– Applications only have as much access to database information as is required to perform their function.
– Finally, database servers have their own security standards, including server-based firewalls, vulnerability management for operating system and RDBMS software, and encryption of critical data.
2.1 Physical Security Infrastructure
ARI maintains a series of physical security infrastructure measures including but not limited to biometric and physical key access control to secured areas and security camera recording, alarm systems and monitoring.
3 COMMITMENTS TO REGISTRANTS
We commit to the following:
– Safeguarding the confidentiality, integrity and availability of registrant’s data.
– Compliance with the relevant regulation and legislation with respect to privacy.
– Working with law enforcement where appropriate in response to illegal activity or at the request of law enforcement agencies.
– Maintaining a best practice information security management system that continues to be ISO27001-compliant.
– Validating requests from external parties requesting data or changes to the registry to ensure the identity of these parties and that their request is appropriate. This includes requests from ICANN.
– That access to DNS and contact administrative facilities requires multi-factor authentication by the Registrar on behalf of the registrant.– That Registry data cannot be manipulated in any fashion other than those permitted to authenticated Registrars using the EPP or the SRS web interface. Authenticated Registrars can only access Registry data of domain names sponsored by them.
– A Domain transfer can only be done by utilizing the AUTH CODE provided to the Domain Registrant.
– Those emergency procedures are in place and tested to respond to extraordinary events affecting the integrity, confidentiality or availability of data within the registry.
4 AUGMENTED LEVEL OF SECURITY
This TLD is a SRSU TLD (.brand style) and as such requires security considerations that are commensurate with its purpose. Our goal with this TLD is to use the TLD internally and adequate protect it against unauthorized registrations or modifications to the namespace, without making the internal process too onerous and thus increasing costs. Whilst, due to the SRSU nature, it is relatively straightforward to restrict and enforce restrictions on registrations, the impact of an unauthorised registration can be high, potentially damaging.
The following attributes describe the security with respect to the TLD:
– ARI, follows the highest security standards with respect to its Registry Operations. ARI is ISO 27001 certified and has been in the business of providing a Registry backend for 10 years. ARI have confirmed their adherence to all of the security standards as described in this application. As per recommendation 24 this ensures that the technical implementations do not compromise elevated security standards
– A single Registrar will be nominated for this TLD, facilitating the tightest possible control over Registrant validity enforcement and domain registration restrictions.
– Registrant will only be permitted to make changes to their domain name after a authenticating to their Registrar.
– Registrants will only be able to access all interfaces for domain registration and management via HTTPS. A reputed digital certificate vendor will provide the SSL certificate of the secure site.
– Registrar identity will be manually verified before they are accredited within this TLD. This will include verification of corporate identity, identity of individuals involved ⁄ mentioned, and verification of contact information
– Registrars will only be permitted to connect with the SRS via EPP after a multi-factor authentication that validates their digital identity. This is described further ahead.
– Registrars will only be permitted to use a certificate signed by ARI to connect with the Registry systems. Self-signed certificates will not be permitted.
– The Registry is DNSSEC enabled and the TLD zone will be DNSSEC enabled. This is described in detail in our response to Question 43. The following additional requirements will exist for Registrars who want to get accredited to sell this TLD:
– Registrars must support DNSSEC capabilities within its control panels.
– If the Registrar provides Managed DNS services to Registrants within this TLD they must provide DNSSEC for the same. This ensures that DNSSEC is deployed at each zone and subsequent sub-zones at Registry, Registrar and Registrant level as per recommendation 26.
– Registrar access to all Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 27. This is described in detail in our responses to Question 24 and Question 25.
– Registrant access to all Registrar and Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 28. This is described in detail in our response to Question 25, Question 27 and Question 29.
– All communication between the Registrar or the Registrars systems and the registry system is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57. This includes the following communication:
– Secure websites and control panels provided by the Registrar to the Registrant.
– Ticketing systems provided by the Registrar to the Registrant.
– Web and EPP interfaces provided by ARI to the Registrars.
– Ticketing systems provided by ARI to the Registrar.
– Any communication between the Registrant, Registrar and Registry that is deemed as critical or contains credentials or sensitive information.
Where these requirements put controls on Registrars these will be enforced through the RRA.
5 RESOURCES
This function will be performed by ARI. The following resources are allocated to performing the tasks required to deliver the services described:
– Executive Management Team (4 staff)
– Production Support Group (27 staff)
ARI has ten years’ experience designing, developing, deploying, securing and operating critical Registry systems, as well as TLD consulting and technology leadership.
As a technology company, ARI’s senior management are technology and methodology leaders in their respective fields who ensure the organisation maintains a focus on technical excellence and hiring, training and staff management.
Executive Management is heavily involved in ensuring security standards are met and that continued review and improvement is constantly undertaken. This includes the:
– Chief Operations Officer
– Chief Technology Officer
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q30(a) – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 1,010 domains, 0.0020% of these resources are allocated to this TLD. See attachment ‘Q30(a) – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The Production Support Group is responsible for the deployment and operation of TLD registries.
The group consists of:
– Production Support Manager (also the ISO)
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support):
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation:
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrators
– 1 Network Engineers
ARI employs a rigorous hiring process and screening (Police background checks for technical staff and Australian Federal Government ‘Protected’ level security clearances for registry operations staff).