Availability of your internet facing service

These scenarios are covered in the NCSC's cyber security design principles (specifically Reduce the impact of compromise and Make disruption difficult), all the principles are relevant to NHS and healthcare organisations.

Protecting the “corporate” network once meant deploying traditional firewalls and intrusion detection solutions at the perimeter of the “trusted network” in order to protect internal applications and data from the dangers of the “untrusted network” or Internet. Even then, these strategies were not very effective at protecting networks from rogue or careless internal users. In the 21^st century, however, just about every NHS and healthcare organisation has published applications to the Internet for remote access. These applications are used by remote healthcare workers, contractors, partners, and customers bearing any number of mobile devices. The result that perimeter security has long since become obsolete as a complete security solution.

As organisations permit customers, partners, contractors and others to access internal applications, they open up their network to malware, data breaches and a variety of other security hazards. The recent parade of damaging, widely publicised breaches of supposedly secure retailers, banks, government agencies and even defence contractors demonstrates the dangers every organisation faces. That’s why securing the network can only be accomplished with a multi-layered, defence-in depth strategy that secures not just the network gateway, but endpoints, servers, network devices, applications and data. Here are security components every organisation should consider deploying to protect its internet facing application access

While it’s no longer a complete solution, any network security strategy starts at the network edge with the perimeter firewall. It’s important to understand, however, that traditional firewalls focus on the network layer, rarely providing protection from application level attacks that traverse commonly open and accessed firewall ports. That means they provide little to no defence against common email and Web based malware, denial of service attacks or more current Web application attacks such as cross site scripting or SQL injection.

Certain measures should be taken to ensure firewalls are used to their maximum potential. Many organisations fall victim to a condition known as configuration drift. Here IT members open up ports or make small, supposedly temporary firewall configuration changes to accommodate any number of users and applications and changes that open their network to attacks and often end up permanent. To protect their networks, organisations should seek out firewalls that include checks for protecting against policy drift, whether in the form of alerts or the capability to check existing configurations against known good configurations, manually or automatically.

Network demilitarised zones (DMZs) are an effective second layer of perimeter defence, providing a separate, less trusted perimeter network between the supposedly trusted and untrusted networks for Internet facing application components such as externally facing Web, email and DNS servers. Traditionally IT configures firewall protection at both ends of the DMZ, between the external Internet and the DMZ and the DMZ and the internal network so that externally facing Web servers have restricted access to internal application and/or database servers. Any users attempting to breach the internal network through externally facing applications must get through two levels of perimeter firewall protection.

With so many different types of users accessing internal applications through multiple devices, identity has become the new perimeter. Identity management tools have become essential to permit access to applications and data only to authorised persons.

Any health or social care organisation publishing applications to local and remote users must ensure it can positively identify and authenticate each and every user and user device attempting to access a published application. Then it must ensure that the user has the assigned rights to access whatever application and data he or she is seeking.

There was a time when usernames and passwords were a viable means of identifying a person or device, but users have been notoriously careless about creating strong passwords and changing them at appropriate intervals and hackers now have a variety of tools to hack even strong passwords.

That’s why any security strategy must include the enforcement of frequent password resets and strong passwords with complex combinations of letters, numbers and symbols, with no 

two accounts sharing the same password. In response to the increasing sophistication of password hacks it is also recommended to implement multi-factor (MFA) authentication.

Multifactor authentication verifies not only something the user knows, such as a username and password, but something the user either possesses such as a smart card, RSA token, SMS message via a smart phone, or a physical attribute of the user such as a fingerprint, face or iris, using the appropriate scanner. These are perhaps the simplest forms of two-factor authentication and make it considerably more difficult for a hacker to pose as a legitimate user.

Once a user is identified, fine grained access control must validate each user’s rights to a requested service and data.

Traditional network firewalls are not terribly effective at stopping application level attacks that employ exploits such as cross site scripting, SQL injection, forceful browsing, and cookie poisoning. Unfortunately, today applications are the most targeted exploit for attackers.

Specialised Web Application Firewalls are architected specifically to stop these kinds of attacks and can be updated to block new application level attacks as they are discovered. Web application firewalls can also detect several data exfiltration techniques used by hackers attempting to steal sensitive data.

DDoS mitigation refers to the process of successfully protecting a targeted server or network from a distributed denial-of-service (DDoS) attack. By utilising specially designed network equipment or a cloud-based protection service, a targeted organisation is able to mitigate the incoming threat.

If a DDoS attack is large enough, it can take out the network infrastructure upstream preventing any on-site solution from being effective. It is recommended to procure a cloud-based DDoS mitigation service and certain characteristics should be evaluated.

Scalability

Aan effective solution needs to be able to adapt to the needs of a growing business as well as respond to the growing size of DDoS attacks. Attacks larger than 2 terabits per second (Tbps) have occurred, and there’s no indication that the trend in attack traffic size is downward.

Flexibility

Being able to create ad hoc policies and patterns allows a web property to adapt to incoming threats in real time. The ability to implement page rules and populate those changes across the entire network is a critical feature in keeping a site online during an attack.

Reliability

Much like a seatbelt, DDoS protection is something you only need when you need it, but when that time comes it better be functional. The reliability of a DDoS solution is essential to the success of any protection strategy. Make sure that the service has high uptime rates and site reliability engineers working 24 hours a day to keep the network online and identify new threats. Redundancy, failover and an expansive network of data centres should be central to the strategy of the platform.

Network size 

DDoS attacks have patterns that occur across the Internet as particular protocols and attack vectors change over time. Having a large network with extensive data transfer allows a DDoS mitigation provider to analyse and respond to attacks quickly and efficiently, often stopping them before they ever occur.

Any organisations allowing external users to access internal applications and data must ensure that any sensitive data traversing the Internet to and from these applications cannot be breached, particularly over an insecure connection such as a public Wi-Fi service used in a hotel, airport, or coffee bar.

Typically, the best way to protect users of these services is through SSL Virtual Private Network solutions that encrypt all application communications over the wired or wireless connection. Ideally all SSL encrypted connections should terminate as close to the application as possible. While other types of VPN’s are available, SSL VPN’s have the advantage of integration with most current mobile and PC Web Browsers, so they are much easier to deploy and use than other VPN solutions that require the client to use separate VPN software.

on the network. However, if an organisation is publishing internal applications to the Internet, in most cases, the closer to the application these solutions are deployed the better. Deploying them on the servers running applications is one solution, but with a multi-server application deployment the risk is that controls will not be applied in a consistent manner to each server. That is why application delivery controllers such as load balancers, are a perfect place to implement security solutions.

Application Delivery Solutions (ADC) provide a highly scalable, high performance, fault tolerant point of access to applications running on multiple servers. Most organisations deploying ADC’s have used them as the point of SSL termination. Moreover, it secures all communications, external and internal, right up to the point of application access.

It stands to reason that the Application Delivery Solutions is also an ideal place for multifactor authentication and a Web application firewall, as these controls can be applied right at the point of SSL termination, just when the data communication is decrypted. This obviates the need to encrypt and decrypt the data in transit several times before reaching the application. Deploying these measures at the ADC rather than each individual server also ensures consistent configurations and policies, combining scalability with security.

A domain name is a meaningful and easy-to-remember name for an internet address.

The domain name system (DNS) is the way that internet domain names are located and translated into Internet Protocol (IP) addresses, and vice-versa. It's a hierarchical system, meaning that each parent domain is authoritative to its child domain.

All NHS domain names are managed centrally via NHS Digital and are protected with security controls and mitigations.

Your main domain name should be recognisable nationally. Generic names (localhealthcampaign.nhs.uk) are not advisable unless aimed nationally. Sub-domains should sit below the main domain name (localhealthcampaign.yourorg.nhs.uk). These are often used for:

• adding host names;
• applications; and
• services.

This improves the performance of the NHS DNS servers and maintains a hierarchical naming structure. When you choose your .gov.uk domain name you must make sure it is:

• available;
• descriptive;
• unique; and
• not confusing for users

Your proposed domain name must clearly describe your organisation or government initiative you’re providing. Think about users of the domain name and make sure the name is not too long or complicated.

Your domain name must:

• be between 3 and 63 characters long
• contain only alphanumeric characters (0-9 and a-z) and the ‘-‘ (dash) symbol
• not be the same or substantially similar to an existing .nhs.uk domain name
• not use ‘&’ (ampersands) or ‘_’ (underscores)
• not include abbreviations like ltd, plc and gov
• not include a postcode

You could use the full name of your organisation, government or NHS initiative or an appropriate suffix.

If you use an acronym, initialism, or abbreviation this must be descriptive, unique and clear to avoid user confusion. Any application for these terms will need approval from the Naming and Approvals Committee. You can use commonly used abbreviations like NHSE, DHSC or UKHSA. You can also use abbreviations that are well-known to your users.

Domain registration rules and restrictions

What are the rules and restrictions for registering domain names?

This article describes some of the rules and restrictions that you need to be aware of when registering a new domain name. These vary according to the type of domain and are dependent on the country with which the domain name is associated.

There are a number of scenarios that the internet first policy doesn't apply to and will require mitigation and additional functions to be between it and the internet, these are:

• databases, no database should be directly connected to the internet and will require an application, security premier, or access gateway with relevant security and audit controls in place
• applications that are only required to be presented on an internal network such as physical security access systems, fire alarm systems, and waiting area digital notice boards
• services where an on-premise medical device requires only a local connection to another; for example a CT Imaging medical appliance to local image storage