All organizations have (or should have) a firewall that blocks unexpected communications from the Internet to internal network hosts. But what about blocking unexpected communications from Internal hosts to the Internet? Many organizations do not spend a lot of time reviewing their outbound access, but maybe they should!
Many of the recently publicized critical vulnerabilities would be largely mitigated if organizations simply blocked unnecessary outbound traffic. The March Microsoft Outlook vulnerability (CVE-2023-23397) that sent encrypted passwords to external attackers when a calendar reminder activated did so over a port (TCP Port 445/SMB), which should be blocked from being sent from workstations to external servers. Many of the recent supply chain vulnerabilities (Kaseya, Log4j, SolarWinds, etc.) could not be exploited if organizations simply blocked outgoing traffic from reaching an attacker’s servers. Many ransomware attacks depend on internal systems communicating with a command-and-control server on the Internet, and blocking outbound access from servers could keep the attack from being successful.
Blocking outbound traffic means first understanding what traffic is necessary from various hosts, which can be a daunting task at first. We know that user workstations will likely need Internet access from a browser, so outgoing access on ports 80 and 443 needs to be open. Depending on the configuration of workstations, they may also need access to email services (like M365) on the Internet. Workstations may also need to have access to a DNS service on the Internet. Other needs may exist and need to be identified, but outside of these few exceptions, organizations should be able to block all other outgoing access from workstations using perimeter firewalls and endpoint firewalls.
When it comes to internal servers, firewall rules should be even more restrictive. A server should have external access to only external servers that are necessary. A server may need to reach out to an application vendor to get patches, but this access should be limited to only the site that delivers the patches. An API on a server may need to communicate with a third party to transfer information, but the firewall rules for the server should limit this outbound traffic to just the third-party servers and only for the ports needed by the API.
We urge institutions to review their policies regarding outbound access and to restrict this access wherever possible as part of their Information Security Program. For assistance with this or other security program controls, please contact Bedel Security at support@bedelsecurity.com to see how we can help!
Additional Resources:
The FDIC InTREX Gets Audited
https://www.bedelsecurity.com/blog/the-fdic-intrex-gets-audited
Discussions Triggered from the LastPass Breach
https://www.bedelsecurity.com/blog/discussions-triggered-from-the-lastpass-breach
Regulators Becoming More Prescriptive
https://www.bedelsecurity.com/blog/regulators-becoming-more-prescriptive
Self-Assessing Authentication & Access Risk
https://www.bedelsecurity.com/blog/self-assessing-authentication-access-risk