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

Prototypical answer:

gTLDFull Legal NameE-mail suffixDetail
.politiePolitie Nederlandvtspn.nlView

The back-end registry operator for .politie is SIDN, the .NL-registry. All operations for .politie will be conducted by the same standards and procedures that SIDN has in place for .NL. The security policy for .politie will be the same as SIDNʹs security policy for .NL. < b r/> SIDN is very proud that .NL, being one of the largest ccTLD’s with almost 5 million registrations, is one of the safest domains according to these independent reports by Norton and McAfee: < b r/> Norton Cybercrime Report (2011) - http:⁄⁄www.symantec.com⁄content⁄en⁄us⁄home_homeoffice⁄html⁄ncr⁄ < b r/> McAfee Mapping the Mal Web (2010) - http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf < b r/>< b r/> SIDN is an ISO 27001 certified organization. (See attachment ’Q30-ISO27001_SIDN.) Security at SIDN is based on the principles of this standard and thus implemented via an Information Security Management System (ISMS) Framework. This framework provides a highly controllable security quality and risk management cycle. < b r/>< b r/> Almost all this documentation is written in Dutch. We have summarized and translated the relevant information from this extended documentation regarding our security policy. Full information is available in Dutch and can be provided if needed. < b r/>< b r/> More detailed information on these topics is provided in the answer to part b of this Evaluation Question. < b r/>< b r/> 1. Security Management < b r/>< b r/> Information security is defined as the process of assessing the required reliability of information systems in terms of availability, integrity and confidentiality, including describing, maintaining and validating a coherent set of related management controls. < b r/>< b r/> SIDN has a pro-active attitude towards information security, aimed at mitigation of consequences and timely recovery of emergencies, and minimizing contingencies. Information security is not regarded as an impediment or cost, but as a way of thinking and working that facilitates SIDN to optimize the role of domain name registry. Attention and efforts regarding information security are taken into account early on in all decision making processes. < b r/>< b r/> The SIDN Security Policy is carried out and fulfilled by all SIDN employees. The CEO of SIDN is overall responsible for security and has assigned a dedicated security officer to handle all security issues for the SIDN. < b r/> Segregation of functions is used as a preventive measure to avoid risks of abuse through separating tasks, authorisations and responsibilities. < b r/>< b r/> SIDN approaches security management on three levels: strategic, tactical and operational. On each level, a dedicated security team is responsible for security management. < b r/>< b r/> SIDN actively participates in several international security-related organisations, including: < b r/> - DNS Changer Working Group (http:⁄⁄www.dcwg.org⁄) < b r/> - The Dutch National Cyber Security Centre (NCSC https:⁄⁄www.ncsc.nl⁄english) < b r/> - Dutch Knowledge Centre for Information Security (Dutch only: PVIB - http:⁄⁄pvib.nl⁄) < b r/> - CENTR Security Working Group (http:⁄⁄centr.org⁄) < b r/> - DNS OPSEC-Trust (https:⁄⁄ops-trust.net⁄) < b r/> - SATIN (Securing and Trusting Internet Names - http:⁄⁄conferences.npl.co.uk⁄satin⁄) < b r/> - DNS⁄OARC (https:⁄⁄www.dns-oarc.net⁄) < b r/> - OpenDNSSEC (http:⁄⁄www.opendnssec.org⁄) < b r/> - Conficker Working Group (http:⁄⁄www.confickerworkinggroup.org⁄) < b r/>< b r/> 2. Audits and Performance Measurement < b r/>< b r/> SIDN maintains a ‘performance-measurement’ program in order to demonstrate the effectiveness of the ISMS and the controls in place. This program consists of auditing, periodic assessments and measurement of Key Performance Indicators. < b r/> Apart from audits, SIDN performs internal monitoring on a structural basis to measure Key Performance Indicators. Key Performance Indicators (KPI’s) are variables used for analysing the effectiveness of the implemented security controls. < b r/>< b r/> Audits are performed on both processes and infrastructure. SIDN performs 4 types of audits: < b r/> - Financial process audit. This audit results in annual accounts that are approved by a certified public accountant. < b r/> - Functional audit on system administration processes. < b r/> - Technical audit and penetration tests. < b r/> - Checks on Key⁄Quality Performance Indicators. < b r/>< b r/> 3. Information Classification < b r/>< b r/> The goal of Information Classification is to provide consistent and structured management of documentation regarding traceability, reproducibility and quality. < b r/>< b r/> Document management describes the document process flow from initiation to management approval, the form and content of documents and the management documents. < b r/> The SIDN Information Classification policy divides SIDN information into 4 categories: Public, Internal, Confidential and Secret. It prescribes when to use these classifications, how to transport it and who may see information. < b r/>< b r/> 4. Access management < b r/> 4.1 Logical Access Management < b r/> The general policy for providing access to SIDN’s infrastructure prescribes that: < b r/> - Only SIDN authorized equipment is permitted access to SIDN’s ICT infrastructure. < b r/> - Authorizations and access rights for a specific system are based on the classification of information (Public, Internal, Confidential, Secret) present in that system. < b r/> - All users are registered. < b r/> - Access and rights are granted on a need-to-know basis. < b r/> - Accounts and passwords are strictly personal and not to be shared. Role- or group-accounts should be avoided whenever possible. Users are not allowed to use someone else’s account or password. < b r/> - The user of an account is responsible for using the account and password. < b r/> - Account information and password must be communicated to the account user separately. < b r/> - Passwords must be stored securely and must not be communicated to third parties. < b r/> - Usage of accounts (specifically logons) will be logged and monitored at all ICT systems. < b r/> - An account name must not reveal any information about its authorization and access rights. An exception is made for default accounts on generic operating systems. < b r/> - Special privileges or the usage of accounts with special privileges must be granted formally by the system or application owner or responsible manager and with a temporal validity. Usage of (accounts with) special privileges should be restricted as much as possible. < b r/> - Access rights and authorizations must be assessed and (re-)evaluated at least twice a year. < b r/> < b r/> The usage of accounts and passwords is the most common way to gain access to ICT systems. SIDN maintains a password guideline for safe usage of passwords. For information systems which contain a classified higher level of information (e.g. Confidential or Secret), additional forms of authentication are in use, such as IP-whitelisting, certificates and chip cards. < b r/>< b r/> System access to all registry systems and network equipment is restricted to employees in specific functions and related roles and is subject to tighter security. < b r/>< b r/> 4.2 Physical Access Management < b r/> Physical Access Management describes the policies and procedures for access to SIDN’s office location and specific area’s and rooms therein and SIDN’s production locations where the infrastructure providing registry services resides. < b r/>< b r/> SIDN locations are only accessible for authorized persons with RFID-tagged access cards that need to be worn visibly. Access cards are strictly personal and only one card per person can be in use. Access to SIDN locations is specific to areas and rooms. Access to server-areas, archive rooms and storage rooms is limited to authorized persons. < b r/> - Access for SIDN employees is based on a personal access card (combined with biometric authentication) linked to specific authorizations. Temporary staff will have access cards with limited validity that need to be renewed periodically. < b r/> - Access for employees of suppliers and partners is based on a personal access card combined with biometrics (2 factor authentication) linked to specific authorizations; < b r/> - Visitors need to report to reception and will be provided a distinguishable visitor access card with limited authorizations. Visitors are accompanied by an SIDN employee at all time during access to the location. This employee is responsible for the visitor during the whole access period. Visitors’ access cards have a standard validity of one day. < b r/>< b r/> Access to SIDN’s production locations is limited to SIDN personnel in specific functions and related roles. < b r/>< b r/> 5. System Security < b r/> 5.1 Systems and networks < b r/> SIDN establishes a baseline including security elements for all information systems (see ‘Risk Management’ below). From a security perspective, these minimal requirements are set for the baseline: < b r/> - All systems have the most recent (security) patches installed; < b r/> - Systems are maintained via encrypted connections only; < b r/> - All non-required software and features are deactivated or removed; < b r/> - System accounts are strictly personal; < b r/> - All system accounts comply with SIDN’s password policy; < b r/> - Usage of the root account is limited to necessary situations only; < b r/> - All systems are monitored and backups are made periodically; < b r/> - System logging is monitored; < b r/> - System logging is archived. Archives are maintained on a separate system; < b r/> - All core systems are located at one of SIDN’s two production locations. All other systems are preferably located at one of SIDN’s two production locations; < b r/> - System administration and maintenance sessions are terminated after a specified duration of inactivity; < b r/> - All HTTPS-web interfaces are based on qualified and valid certificates; < b r/> - All passwords are stored encrypted; < b r/> - Systems are behind firewalls, unless specified otherwise; < b r/> - Configuration of firewalls is based strictly on a ‘closed-unless’-principle. < b r/>< b r/> 5.2 DNS < b r/> To ensure the correctness of updates between the registry systems and the pool of available DNS servers the following mechanisms are in place: < b r/> - DNS zone file is generated using the registry database; < b r/> - Zone file is checked for missing glue records and if ok, transferred to the DNSSEC signer machines; < b r/> - On the signer machines, the zone file is DNSSEC signed; < b r/> - Next to that validity checks are in place to ensure the correctness and completeness of the zone file; < b r/> - If still ok, the zone file if transferred to the pool of master DNS servers; < b r/> - The master DNS servers send notify messages to all slaves telling an update is available; < b r/> - The slaves contact the master servers to retrieve the updates. < b r/>< b r/> The communication between master and slave name servers is TSIG protected. This means that all data is exchanged in a secure way. Next to that a firewall cluster only allows access to the master DNS servers when traffic is coming from a slave IP address (ether IPv4 or IPv6). < b r/>< b r/> Orphaned Glue < b r/> With respect to the orphaned glue, apart from the zone file checks, the following measures are in place to mitigate to danger of having orphaned glue. < b r/> When a domain name is deleted from the Shared Registry System, the domain name is going into redemption grace for 40 days. During this period no changes can be made to the registration, and the only possible transaction is restoring of the domain name. If no restore transaction has been done, after these 40 days, the registration will be deleted and the domain name becomes available for registration. Upon deletion of the registration, all sub ordinate host objects are also deleted in the Shared Registry System, possibly leaving other registered domain names depending on these hosts with less than the minimum required number of name servers. If a registered domain name is left with no linked hosts (name servers), the registration status will be inactive, and the domain name will not be included in the zone file. < b r/>< b r/> DNS Abuse < b r/> Abuse prevention and mitigation is part of the security policies regarding DNS. SIDN’s DNS servers are intended to enable people to find .politie domains in the context of normal Internet use. However, it sometimes comes to SIDN’s attention that the servers are being used for other purposes. Such abuse puts unwanted pressure on system capacity and, in extreme circumstances, could prevent the servers from being used for their proper purpose. This could constitute a denial of service (DoS) attack and compromise the working of the Internet. < b r/>< b r/> Abuse in this context is defined as any form of DNS server usage that isn’t part of normal Internet use. SIDN always regards the following as abuse: A single party’s prolonged or repeated generation of traffic whose volume exceeds the total volume of all normal Internet traffic. < b r/> SIDN has policies prescribing specific actions for handling DNS abuse upon detection. < b r/>< b r/> 5.3 Back-Up < b r/> Availability of information is critical to SIDN’s business processes. Depending on the type of information, data is duplicated and stored. Stored data and backups are made periodically. All information has a dedicated ‘owner’ who is responsible for backup schemes. < b r/> Backups are stored physically and geographically separated from the operational information systems. The information systems themselves are located at two geographically separated locations. Backups are stored at a certified supplier of data-backup storage. < b r/>< b r/> 5.4 Logging and Monitoring < b r/> All core systems are logged and logging is stored and processed through a Log Management System. Stored logging is kept for a minimum of 1.5 years and contains Syslog and system values (e.g. interface throughput, use of memory, processor usage). < b r/> The Log Management System also checks logs for at least: < b r/> - Errors; < b r/> - Failed logins; < b r/> - Suspected user logins; < b r/> - Successful Backups; < b r/> - Network changes, configuration backups; < b r/> - Loss of redundant network interfaces; < b r/> - Performance of firewalls; < b r/> - Types of Spam. < b r/>< b r/> All core systems and applications are monitored. Monitoring is done by comparing pre-defined baseline values and thresholds to actual values and parameters. By crossing of a threshold, alerts are generated. These alerts generate notifications to multiple dedicated SIDN employees. If an alert relates to an incident, an incident ticket is created. < b r/>< b r/> 5.5 External Network Connections < b r/> External interfaces are interfaces that have access to SIDN’s infrastructure from a third party network or environment. Authorisation to connect to SIDN’s infrastructure can only be obtained after signing of a Non-Disclosure Agreement by the third party and signing the policy for connecting external interfaces. Risks involved in maintaining these interfaces are managed through a policy. < b r/>< b r/> 5.6 Software Development < b r/> The Shared Registry System is an in-house developed system and many of our other registration services systems and connections between systems rely on proprietary software. Software updates and releases are subject to the Change Management Process, which is based on ITIL (see section 6 below). < b r/>< b r/> SIDN maintains a full DTAP (Development, Test, Acceptance, Production) street for development. With separated systems supporting each phase. < b r/>< b r/> Quality of software is controlled through external auditing by SIG (Software Improvement Group - http:⁄⁄www.sig.eu⁄en). The SRS application (DRS 5.0) is certified with 4 stars out of 5 on maintainability by SIG⁄Tüvit (see attachment ‘Q30-Tuvit’). < b r/>< b r/> Development at SIDN is based on ‘test driven development’. This requires starting with a unit test before developing new functionality. SIDN requires that 80% of all written code is covered by unit testing. Next to the Development Team, SIDN has a dedicated Test Team. All members are ISQTB certified (http:⁄⁄www.istqb.org⁄). The Test Team tests all software through functional application testing and regression testing. The Test Team also supports end users with acceptance testing. < b r/>< b r/> 6. Processes < b r/>< b r/> SIDN’s ICT department has several security-related management processes based on ITIL and employees are required to apply them in the following ICT management processes: < b r/> - Security Incident Management < b r/> - Change Management < b r/> - Problem Management < b r/> - Configuration Management < b r/> - Release Management < b r/> - Capacity Management < b r/> - Vulnerability Management < b r/> - Patch Management < b r/>< b r/> 7. Risk Management < b r/>< b r/> The Risk Management Process is an integral part of the ISO27001 methodology and covers a systematic and periodic approach to all activities aimed at: < b r/> - Identification and quantification of possible risks; < b r/> - Establishment and implementation of mitigating measures to both reduce the chance of occurrence and limit consequences of risks. < b r/>< b r/> As part of a yearly cycle within the Risk Management Process, all primary business processes are reviewed and scored for business impact. Every process and information system is qualified as ‘normal’, ‘relevant’ or ‘critical’ on three aspects (availability, integrity and confidentiality). < b r/>< b r/> SIDN works with a risk matrix that relates inventoried risks to baseline measures from the ISO 27001 standard and to additional measures taken through the risk management process. The full matrix is quite elaborate and written in Dutch. An excerpt with the most relevant threats and assessments is translated in English. Both documents are provided as an attachment to 30b. < b r/> < b r/> 8. Business Continuity Management < b r/> Business Continuity Management (BCM) is the process that structurally approaches detrimental internal and external influences and threats to business processes and mitigates them to an acceptable level. SIDN distinguishes between a regular and an emergency BCM process. < b r/> The regular BCM process covers the process of description, operation, monitoring and reviewing during regular operations. The emergency BCM process covers the process of identification of a disaster, recovering from it and coming back to normal operation as soon as possible. < b r/>< b r/> The scope of the BCM processes are focused on critical business processes. BCM ensures maximum availability of the core business services. The CEO of SIDN has overall responsibility for the whole organisation and thus for Business Continuity Management. < b r/>< b r/> SIDN’s infrastructure is redundantly spread out over several locations, with geographically separated locations for infrastructure supporting registry services, DNS services and system management. < b r/>< b r/> SIDN has contingency plans to facilitate relocation of both infrastructure and staff in case of emergency. All systems providing registry services are hosted at two production locations that are both operational and both contain accurate data and available services. DNS services are supported by a widely distributed system, consisting of several unicast name server clusters and three anycast networks, all hosted at certified data centres. SIDN’s office location contains no systems supporting registry functions. Infrastructure relocation is tested periodically and showed a recovery time of all registry services in less than 10 minutes during the last test, with no outage for DNS services. < b r/> In case SIDN’s office location is lost (e.g. through fire or flooding), a backup site is available. This backup site also provides facilities for a partial relocation (e.g. if primary communication channels are lost). Relocation to the backup site is tested annually. These tests show that in case of a relocation, full office functionality is restored within 4 hours.

Similar gTLD applications: (2)

gTLDFull Legal NameE-mail suffixzDetail
.amsterdamGemeente Amsterdamamsterdam.nl-4.02Compare
.overheidnlministery of the Interior and Kingdom Relationsminbzk.nl-4.01Compare