.EU domains after Brexit

In March 2018, the European Commission announced that businesses and individuals in the United Kingdom could no longer register or renew .EU domains upon departure from the European Union. Consequently, it was necessary to decommission the Cyber Threats website and redirect all the traffic to this site.

More information is available here: https://ec.europa.eu/digital-single-market/en/news/notice-stakeholders-withdrawal-united-kingdom-and-eu-rules-eu-domain-names

I identified several potential workarounds in response to Brexit, such as establishing a virtual office in another EU member state or using an EU-based service provider as the domain’s registered owner. These solutions may have worked initially and allowed the domain names to remain active. However, the spirit of the decision is that .EU domains are for EU based individuals and businesses resident within the EU.

Defining Access Control Policies

Access Control comes in many different flavours depending on the business, the systems used, and the buildings protected. At the same time, access control has a generic theme. Consequently, the policies put in place will be similar across the board, even when specific implementations of access controls can be very different.

Sections of an Access Control Policy may seem self-explanatory; however, it is worth remembering that the policies will be read and adhered to by non-technical staff and staff not experienced in Information Security.

With this in mind, the following three points give an overview of the policy; which could be defined as three sections or presented as a single policy statement. It could be one section. The following are examples of what to think about when describing the policy.

  • Policy Statement – protecting access to systems is critical to maintaining the integrity of our technology and data while preventing unauthorised access
  • Background – Access Controls are necessary to restrict access to authorised personnel only
  • Policy Objective – the objective of this policy is to ensure that we have adequate controls in place to restrict access to systems and data.

Defining the scope of the policy is essential to show where and how it will be applied. Here are some examples of what to include:

  • Locations – this policy applies to our offices in London, Liverpool and Glasgow. Alternative policy documents may exist for different offices because of regional legislative differences.
  • Who – this policy applies to all employees, consultants and 3rd party vendors authorised to access our systems
  • What – this policy applies to the use of desktops, laptops, business systems and mobile devices

A specific section to document all technical terms and their definitions is essential for non-technical members of staff to understand. Examples could include Access Control, Users, Business System Accounts, Application Accounts, Privileged Accounts, Access Privileges or Permissions, Elevated Permissions, Services Accounts, Test Accounts and others.

Access Control Requirement sections could include:

  • All users must use a Unique ID to access systems
  • Define passwords following the Password Policy
  • Remote access must use two-factor authentication
  • Sessions lockout or screensaver activation after 15 minutes of inactivity

General principles would typically include:

  • Access provided based on Least Privilege and Need to Know
  • User account requests and approvals logged and documented
  • How the policy applies to vendor accounts, application and service accounts, system administration accounts, shared generic accounts and test accounts
  • Restricted access to service account passwords
  • Non-expiring passwords
  • User account access terminated when people leave the organisation
  • Accounts set to expire when contracts expire or after a period of inactivity
  • Adequate user identification when new passwords are requested

Principles specific to privileged accounts

  • For a privileged account, create it as a named user account and not a generic user account. E.g. “ADM.firstname.surname”
  • Privileged user accounts requested by line managers
  • Monitoring of privileged account usage

Other thoughts

  • Define what happens with vendor default user names and passwords
  • Define the policy on test accounts
  • Define any specific considerations for access control for 3rd party vendors and contractor user accounts

Different people and teams will have roles and responsibilities under this policy, and these need to be defined. Consider who will be responsible for the following policy roles:

  • Who has ultimate responsibility for the policy?
  • Who will review and approve the policy?
  • Who will develop and maintain the policy over time?
  • Who will be responsible for taking proactive steps to reinforce compliance?
  • Line Manager support for their direct reports in understanding the requirements
  • Commercial team responsibility for 3rd party obligations
  • Reporting requirements for non-compliance
  • Human Resources requirements for new employees
  • Requirements for all staff