Asset Lifecycle Management

Below are the steps you must consider when implementing this control.

Analyse and understand your environment

First you need to verify and document the different networks that your organisation has. Large or organically grown networks can be challenging to fully understand. You need to consider any hosts you have on your networks, as well as any services on cloud providers such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform.

For all cloud services you have identified are in use in your organisation, check for internet-exposed services. This includes servers you manage on that provider (infrastructure-as-a-service or IaaS), and services such as databases or object storage (platform-as-a-service or PaaS).

Different cloud providers have different ways to carry out this investigation. For PaaS services, check the settings to determine whether the service can be accessed from the internet. For IaaS, you will need to look at the virtual networking defined in your provider, and note any public IP addresses allocated. This should also allow you to check what ports might be exposed to the internet.

For services you host, determine what public IP address range(s) you use. You may need to review configuration of your network devices, or ask your ISP to confirm what ranges are in use. Again, reviewing the configuration of your network devices should show you what ports are exposed to the internet

Scanning the public IP addresses you identified in the previous steps will help you confirm which ports are open, what services are running, and what protocols are supported. There are many network scanning tools that can help you with this. Some tools need to be run from your own systems, and some can be used in a Software-as-a-Service model. Examples of both include OpenVAS or Tenable Nessus. Be sure to trial and test a tool first, and make sure it can identify the hosts across your various and complex networks.

When scanning, the outputs might be overwhelming. The services or outputs you want to focus on will be:

• services that return banners for common mail services, such as Outlook Web Access
• remote access services running on standard or non-standard ports, such as RDP or SSH
• VPN services
• any services running that allow someone outside your network to gain access to internet systems, such as web mail or storage systems.

Now you should have a full list of all your organisation’s resources that are exposed to the internet, across all service providers. This list will start to age quickly, so automating the discovery of these services will be important. This could be through regular scans through your known public IP ranges, or through exports of any cloud resource management portals you have access to.

Assess your internet-exposed services and resources

Next you want to understand:

1. Is this service or resource still required?
2. If so, does my organisation need this service to be internet-accessible?
3. If so, does it need to be completely exposed to all sources on the internet or can it be restricted by IP/CIDR or geolocation?

It will be important to answer these questions in the context of the access and data they expose. For example, if your organisation exposes database servers to the internet, this can present a serious risk to the information in those databases, and to your organisation. It would be better to restrict access to this server via a VPN rather than giving it a public IP address.

Once assessed, your list of services and resources will include:

• shared cloud resources, with varying levels of access from full internet-exposed, to restricted by source, to restricted to private network access only
• services and protocols running on your own private network resources. These will vary in level of access and support that are managed by your organisation.

Configure and harden your services

With a better understanding of what services and resources you use, you can configure and harden them according to their needs.

• Any services or resources that are not needed should be disabled. This reduces the attack surface of your network and reduces the areas where things can go wrong.
• Any services or resources that can be protected with an easy-to-identify list of source IP/CIDR or locations should be restricted to do so. Although restricting by source can be an easy control to bypass once identified, it can prevent attackers going for low-hanging fruit that are listed in public search engines or scan results.

Regardless if a service or resource has a source-based access control, any enabled service or resource should be hardened. This includes:

1. Patching all software for all internet-exposed services. Internet-exposed services are routinely scanned by attackers, and vulnerable systems can be compromised within hours of a new vulnerability being announced. Internet-exposed services need to be patched quickly when new updates are released in order to mitigate this risk.

   Patching

2. Configuring and requiring multi-factor authentication. Anyone will be able to attempt to authenticate against these services and resources. You will find people trying all sorts of password spray, re-use, and brute-forcing attacks. Strong multi-factor authentication, using either push-based or hardware security keys, is a way to prevent these attacks from being successful. For more details on multi-factor authentication, refer to our other critical controls.

3. Ensuring only necessary and modern protocols are supported. For all services that need to be exposed to the internet, review the specific protocols and protocol versions available, and disable any that are no longer needed.

   Disabling unnecessary services and protocols

Monitor for security events

After configuring logging for your services and resources, you will need to configure alerting or review them for security and important events. The security events you will want to consider will be:

• Authentication events
  • Failed authentication can be a high volume event, leading to alert fatigue. You might consider alerting based on multiple failures, or failures from new geographies, that might indicate an attempt to compromise your system. Failed authentication of administrative accounts should be lower volume, and due to their sensitive nature, should be looked at more closely.
• Operational events
  • Important events include actions performed by administrative or privileged users. Any actions performed by an administrator should be checked to make sure it was expected. Important configuration or changes to monitor would be authentication changes (such as requiring multi-factor authentication) or enabling or new ports or services (such as RDP or SSH), or changing security controls and software (such as endpoint detection software or logging controls).
• Performance events
  • Important events include tracking and baselining throughout and number of requests, and uptime. Any changes from a normal baseline might indicate an incident occurring, and any drastic changes might incident an availability or denial of service attack. For example, unexpected sustained high CPU usage on a VM can be an indicator of crypto-mining software being deployed

Additional details and support for configuring alerting can be found in your critical controls.

Centralised logging