Explanation:
Scan your environment to know which ports are open, what services are running, and what protocols are supported. Network scanning software such as Opencast, Sureness, or Alien vault OS SIM 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.
TIP: 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 scantness to confirm which version of SSL/TLS your web server supports. Compare this against the network scans to double check they're accurate.
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, TS 1.0 has had many vulnerabilities uncovered, and TS 1.2 offers additional protection over TS 1.1. TS 1.3 will soon be confirmed as a standard, and offers further improvements over TS 1.2.
Confirm if any outdated protocols can be upgraded. At installation, a web server may enable TS 1.0, TS 1.1, and TS 1.2 protocols by default. In this example, disabling protocols older than TS 1.2 would require all users connecting to your web server to use TS 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 (MED). 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.
TIP: 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.
TIP: 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 TS protocol example, you may choose to keep the outdated TS 1.1 enabled. This could be due to the number of users that connect to your website with a browser that only supports TS 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 TS 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 TS 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.
TIP: 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.
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 centralizer 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.
TIP: 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.
