Scan and analyse your environment
Scan your environment to know which ports are open, what services are running, and what protocols are supported. Network scanning software such as OpenVAS, Nessus, or Alienvault OSSIM can let you know what devices have what services running, and what protocol versions are supported. Particularly in larger networks, the results can be surprising.
Cross-validate the results of your network scan by manually retesting any business critical or internet-facing services. While automated scanning is an invaluable tool, false positives or negatives are possible. For example, you could use a tool like sslscan to confirm which version of SSL/TLS your web server supports. Compare this against the network scans to double check they're accurate.
Verify which services and protocols you need
Review the results of the network scan to understand which services and protocols are required.
- Confirm if the open ports and the services using them are still necessary. When software is installed, services are often auto-enabled that aren't necessary for the features you use.
- Once you know which open ports are needed, find out which services and protocols are outdated. These will often be exposed to known vulnerabilities. For example, TLS 1.0 has had many vulnerabilities uncovered, and TLS 1.2 offers additional protection over TLS 1.1. TLS 1.3 is also available, and offers further improvements over TLS 1.2.
- Confirm if any outdated protocols can be upgraded. At installation, a web server may enable TLS 1.0, TLS 1.1, and TLS 1.2 protocols by default. In this example, disabling protocols older than TLS 1.2 would require all users connecting to your web server to use TLS 1.2 (or newer) and may prevent users from connecting if they are using older web browsers (clients).
- Find out what the impacts on the business would be if outdated services and protocols were disabled. Before disabling any services or protocols, it is important to understand any impact. For example, SMBv1 is obsolete and insecure, but is still used by many multi-function devices (MFD). Simply turning it off may have unintended effects on your business. You may need to reconfigure or replace any devices still using old protocols, before you can disable them. Any devices that can’t be replaced or reconfigured, must be managed as legacy systems.
Performing this review will take time and resources. Document all the information you learn and exceptions you find so you don’t have to repeat all the work in the future.
Disable services and protocols that are not needed
Close the ports and disable the services and protocols that are not needed. This should be done on both the server side and the client side. Any services or protocols that do not have a business need are unnecessary and must be disabled.
These services and protocols should be disabled on the host level. Using technologies like firewalls to block them is only a partial mitigation.
A risk and business decision needs to be made if the services or protocols have a business need and are outdated or vulnerable. In the TLS protocol example, you may choose to keep the outdated TLS 1.1 enabled. This could be due to the number of users that connect to your website with a browser that only supports TLS 1.1 and lower. This may be acceptable because there are no current critical public vulnerabilities for that protocol. You may also choose to disable TLS 1.0 because the risk of keeping it enabled with the current known vulnerabilities is too high, even if some website visitors use an old browser that only supports TLS 1.0 or lower.
If you’re unsure if there is a business need for a service or protocol, there are ways to verify it. You could enable and review audit logs to see which protocols are in use. Another way to verify it is by temporarily disabling the service or protocol and see what happens. A service or protocol should not remain enabled because you're unsure if you need it.
If your organisation makes a business decision to keep an outdated service or protocol enabled, then you need to treat it like a legacy system and monitor it for misuse. For example if you have the SMBv1 protocol enabled for the printers on your network, actively monitor them to detect connections that do not resemble normal traffic patterns for that print service.
Use standard builds and monitoring
By using standard builds, you don’t have to manually fix issues on each machine. A centralised configuration management tool can make it easier for these changes to be made.
For example, if you have agreed that your web server needs specific protocols to operate, add these configurations to your web server image that you deploy, so that all future servers are configured the same. This saves you time from performing manual checks to make sure no unnecessary or outdated services or protocols are enabled by accident. For the servers that are already running, changes to protocols can be made by the centralised configuration management tool.
Performing a scan and analysis of your environment is a helpful point-in-time test. These scans should be performed periodically to make sure configurations have not drifted or changed over time.
Use network monitoring to detect when someone might be enabling unnecessary or outdated services and protocols. In some environments, you can set alerts when network changes are made to your servers that open up new ports. These alerts could be automated to either prevent specific, high risk configuration changes from being made or to notify someone to investigate.