.mlb DNSSEC Policy

4.2 Procedural controls

4.2.1 Trusted Roles

The following table presents all procedures that we have implemented for providing DNSSEC services for the TLD. These procedures require corresponding roles as below:

Key Rollover: System Administrator, Security Officer
Key Creation: System Administrator, Security Officer
Disposal of old Key: System Administrator, Security Officer
KSK Rollover: System Administrator, Security Officer

4.2.2 Number of Persons Required Per Task

The number of persons required varies per task or procedure. Please refer to Section 4.2.1 for further information.

4.2.3 Identification and Authentication for Each Role

We require all personnel dealing with secure DNSSEC material and systems to have completed security checks. We reserve the right to interpret the findings of the security check equitably with respect to the secure nature of this DNSSEC implementation as covered by our Human Resources policy.

4.2.4 Tasks Requiring Separation of Duties

Tasks that are part of a Key Rollover require separation of duties. Please refer to Section 4.2.1 for further information.

4.3 Personnel Controls

4.3.1 Qualifications, Experience and Clearance Requirements

Each person who fulfils a DNSSEC role must:

• Be employed full time by us;
• Not be within their initial employment probation period; and
• Have completed a security check,

4.3.2 Background Check Procedures

A security check must be completed prior to taking part in DNSSEC tasks.

4.3.3 Training Requirements

Each person who is responsible for DNSSEC tasks must have attended our DNSSEC training session and be Tully qualified to perform that function.

We provide frequent retraining to our employees to assist them with keeping their skills current and enabling them to perform their job proficiently.

4.3.4 Job Rotation Frequency and Sequence

We rotate the responsibility for DNSSEC related tasks between staff that satisfy the skill set required to execute those tasks.

4.3.5 Sanctions for Unauthorized Actions

We will conduct investigations where we detect or are made aware of unauthorized actions on the DNSSEC environment. We will take necessary disciplinary action should such action be warranted.

4.3.6 Contracting Personnel Requirements

Contractors and consultants are not authorized to participate in secure DNSSEC tasks.

4.3.7 Documentation Supplied to Personnel

We provide requisite training and support material to our employees to enable them to proficiently perform their duties. Supplied documentation is provided to staff under security controlled guidelines to ensure operational security.

4.4 Audit Logging Procedures

All systems deployed utilize audit log functionality which is coordinated centrally. Logging is used to monitor the health of systems, trace any issues and conduct diagnosis.

4.4.1 Types of Events Recorded

A high level categorization of events that are recorded is as follows:

Zone File Activity: Addition and removal of domain names. Changes in Resource Records associated with domain names in the TLD.
Hardware Failures: Failure of server and network infrastructure or their components.
Access To Hardware: Changes in access controls granting physical, console and network access to infrastructure.
Security Profile: Changes in settings and configuration that determine the security of infrastructure or the services it provides.
System Updates: Updates to operating environment and packages on servers and firmware on network appliances.
Network Activity: Divergences from observed patterns of network activities.
Redundancy Failure: Failure in backups, Disaster Recovery or transitions between primary and secondary site.
Incident Management: Incidents being raised, allocated, acted upon and resolved.
Failure In Event Monitoring: Failure of event monitoring system. This would be detected using a secondary event monitoring system.

4.4.2 Frequency of Processing Log

Audit logs and event monitoring feed into our monitoring system that raises alerts based on states that are not normal in regular operations.

4.4.3 Retention Period for Audit Log Information

Audit log information is securely archived for a period of 7 years.

4.4.4 Protection of Audit Log

Audit logs are only available to our staff with appropriate privileges. Audit logs do not contain private keys or other sensitive information that may lead to a compromise by using existing and known methods.

4.4.5 Audit Log Backup Procedures

Audit logs are backed up as part of the backup procedures in place for production systems. Those logs containing sensitive data are stored in a secure manner. Disposal of audit logs is carried out in accordance with Section 4.1.7.

4.4.6 Audit Collection System

In addition to information recorded manually by staff while conducting operations, Audit information is collected in Audit logs automatically. Methods specific to applications and operating environments are used to record audit logs.

Manual logs are scanned and the original documents archived in a fireproof safe.

4.4.7 Notification to Event-causing Subject

No notification is issued to the event-causing subject as part of automatic event logging. However, selected events are monitored and alerts delivered to our employees that may choose to notify event-causing subjects.

During execution of manual procedures the participants are informed that logging is taking place.

4.4.8 Vulnerability Assessments

We engage an external entity to perform a vulnerability audit annually. This is in addition to monitoring and analysis that is in place for production systems. A broader annual compliance audit is also performed as discussed in Section 7.

4.5 Compromise and Disaster Recovery

4.5.1 Incident and Compromise Handling Procedures

Any event that may cause or has caused an outage, damage to the Registry, or disruption to service is classified as an incident. Any event that is an incident and has resulted in exposure of private DNSSEC components is classified as a compromise. Incidents are addressed using our incident management procedures.

Should we detect or be notified of a compromise, we will conduct an investigation in order to determine the nature and seriousness of the compromise. Following the investigation we will take the necessary measures to re-instate a secure state. This may involve rolling over the ZSK(s), KSK(s) or both.

Incident management is conducted in accordance with our Incident Management Process.

4.5.2 Corrupted Computing Resources, Software and/or Data

Detection or notification of corrupted computing resources will be responded to with appropriate incident management procedures and escalation procedures as necessary.

4.5.3 Entity Private Key Compromise Procedures

An emergency ZSK and KSK rollover will be carried out in the event that we detect or are notified of a private key compromise of either key. On suspicion of a compromise, we will instigate an investigation to determine the validity of such suspicions. We will notify the public through an update that will be published in accordance with Section 2.2.

4.5.4 Business Continuity and IT Disaster Recovery Capabilities

Business continuity planning and disaster recovery for DNSSEC is carried out in accordance with our Business Continuity and Disaster Recovery Policies, and contracts in place with the Registry Operator.

4.6 Entity Termination

We will ensure that should our responsibilities to manage DNS for the TLD be terminated, we will co-ordinate with all required parties in order to execute a transition.

Should it be decided to return the TLD to an unsigned position, we will endeavor to carry it out in an orderly manner.

5.1 Key Pair Generation and Installation

5.1.1. Key Pair Generation

The generation of KSK and ZSK is carried out by following the relevant procedure to generate keys of the strength required for the TLD.

Key Pair Generation is an audited event and audit logs are recorded and kept in accordance with relevant policies.

5.1.2 Public Key Delivery

The DS is delivered to the parent Zone using a secure and authenticated system provided by IANA.

The DNSKEY is published in the DNS.

5.1.3 Public Key Parameters Generation and Quality Checking

In accordance with Section 4.2.1, one of our employees carries out the public key generation. Quality of the parameters is examined as part of our standard change control procedures.

5.1.4 Key Usage Purposes

Keys will be used in accordance with the DNSSEC implementation defined in this DNSSEC Practice Statement and other relevant documents such as agreements stated in Section 1.3. The keys are not exported from the signing system in an unencrypted form and are only exported for backup and disaster recovery purposes.

5.2 Private Key Protection and Cryptographic Module Engineering Controls

All cryptographic operations are carried out within the signing system. The private components of keys stored on the signing system are exported in encrypted forms only for backup and disaster recovery purposes.

5.2.1 Cryptographic Module Standards and Controls

Systems used for cryptographic functions must be able to generate acceptable level of randomness.

5.2.2 Private Key (m-of-n) Multi-person Control

Procedures for KSK generation and key signing implement an M-of-N multi-person approach. Out of N authorized persons that can participate in key generation or key signing, at least M need to be present.

5.2.3 Private Key Escrow

Private components of keys used for the Zone are escrowed in an encrypted format in accordance with ICANN specifications.

5.2.4 Private Key Backup

Private components of keys used for the Zone are backed up in an encrypted format in accordance with our backup and disaster recovery policies.

5.2.5 Private Key Storage a Cryptographic Module

Private keys are stored on the signer system and restricted to be only accessible to signing functions.

5.2.6 Private Key Archival

Old keys are archived for a period of seven years in an encrypted form.

5.2.7 Private Key Transfer into or from a Cryptographic Module

There are no circumstances under which a private key would be transferred into the signing systems.

In accordance with Section 4.6 and in consultation with the relevant stakeholders, a private key can be transferred out of these systems. The private key will be transferred to the relevant stakeholder in encrypted form unless specifically requested otherwise by that stakeholder.

5.2.8 Method of Activating a Private Key

Keys are activated during a Key Rollover with the appropriate employee executing the rollover procedure.

5.2.9 Method of Deactivating a Private Key

A private key is deactivated by removing all signatures that deem the key valid and subsequently removing the DNSKEY record from the Zone. In the case of a KSK, the DS is removed from the root Zone. The exact order of this is dependent on the rollover method being used. Rollover methods are detailed further in Section 6.

5.2.10 Method of Destroying a Private Key

We destroy keys by securely removing them from the signing system. However, encrypted backups of the keys are not destroyed but rather archived as described in Section 5.2.3,

The signing system may be de-activated following pre-configured triggers that indicate suspicious activity for example, a reboot of the signing system.

5.3 Other Aspects of Key Pair Management

5.3.1 Public Key Archival

Public components of keys are archived as part of backups and disaster recovery procedures.

5.3.2 Key Usage Periods

KSK: 1 year
ZSK: 3 months
Signature Validity Periods: 30 days

Note: Keys that have been superseded are not used to sign Resource Records.

5.4 Activation Data

Activation data is securely generated and is protected by a confidentiality agreement between us and stakeholders that hold activation data. Activation data is decommissioned by destroying, invalidating or by using another suitable method applicable to the type of data.

5.5 Computer Security Controls

We limit access to production servers and only authorized staff members from our IT department are allowed privileged access. Access may be extended to other personnel for valid business reasons.

Authentication methods are complimented with network security measures. Passwords are rotated regularly and best practices such as tiered authentication and two factor authentication are implemented where appropriate.

5.6 Network Security Controls

Networks for secure DNSSEC infrastructure are segregated using firewalls. Audit logs are kept for all sensitive DNSSEC operations and archived for investigative purposes should security breaches be suspected or detected. Systems are divided into their applicability (e.g. frontend and backend) and user and application access to them is restricted using appropriate means. Production infrastructure is logically separated from non-production infrastructure to limit access at a network level in accordance with our security policies.

5.7 Time Stamping

Timestamps are used for:

• Audit logs generated manually and automatically; and
• DNSSEC signatures.

We synchronize our timeservers with stratum 2 or 3 timeservers. All manually recorded times are stated in time that is local to the location of record. All automatically recorded times are in UTC.

5.8 Life Cycle Technical Controls

5.8.1 System Development Controls

All software deployed on production systems is maintained in version controlled repositories. We implement rigorous change control systems for production infrastructure.

5.8.2 Security Management Controls

We monitor our system for access, configuration changes, package installs and network connections in addition to other critical metrics that can be used to detect suspicious activities. Detailed audit logs enable us to trace any transaction on our systems and analyze events.

5.8.3 Life Cycle Security Controls

We implement fully redundant signing infrastructure and contracts with hardware manufacturers to provide 4 hour business day turnaround on support.

All production infrastructure and software is thoroughly tested before being deployed. Source code of all software deployed to production systems is authenticated and verified.

8.2 Financial Responsibility

Not applicable.

8.3 Confidentiality of Business Information

8.3.1 Scope of Confidential Information

The following information is kept confidential and requires privileged access as controlled by our policy:

• Secure DNSSEC information
• Audit logs
• Reports created by auditors
• Procedures
• Policies that relate to security

8.3.2 Types of Information Not Considered Confidential

Information that is classified as public as part of the DNSSEC extensions to DNS are considered to be public by us and will not be subject to access restriction.

8.3.3 Responsibility to Protect Confidential Information

We are committed to the confidentiality of information and takes all measures reasonably possible to prevent the compromise of such information.

8.4 Privacy of Personal Information

8.4.1 Information Treated as Private

Not applicable.

8.4.2 Information not Deemed Private

Not applicable.

8.4.3 Responsibility to Protect Private Information

Not applicable.

8.4.4 Disclosure Pursuant to Judicial or Administrative process

We shall be entitled to disclose confidential/private information if we believe that disclosure is necessary in response to judicial, administrative, or other legal processes.

8.5 Limitations of Liability

We, to the extent permitted by law, exclude liability for any losses, direct or indirect, punitive, special, incidental or consequential damage, in connection with or arising out of this DNSSEC Practice Statement or the actions of us or any third party (including for loss of profits, use, data, or other economic advantage), however it arises, and even if we have been previously advised of the possibility of such.

8.6 Term and Termination

8.6.1 Term

This DNSSEC Practice Statement becomes effective upon publication with the most current version being published.

8.6.2 Termination

This DNSSEC Practice Statement will be amended as required and will remain in force until it is replaced by a new version.

8.6.3 Dispute Resolution Provisions

Disputes among DNSSEC participants shall be resolved pursuant to provisions in the applicable agreements among the parties.

With the exception of injunctive or provisional relief, disputes involving us require an initial negotiation period of no less than 60 days prior to the commencement of legal action.

Subject to the foregoing, any legal action in relation to this DNSSEC Practice Statement against any party or its property may be brought in any court of competent jurisdiction in the State of Arizona, United States of America and the parties irrevocably, generally and unconditionally submit to the nonexclusive jurisdiction of any court specified in this provision in relation to both itself and its property.

8.6.4 Governing Law

This DNSSEC Practice Statement shall be governed by and construed under the law in the State of Arizona, United States of America.

8.6.5 Registry Jurisdiction

The Registry Service Provider operates in the State of Arizona, United States of America.