Zero Trust for Software Updates
Consider network requirements when purchasing products
One of my posts on Network Security, the SolarWinds Breach, and Data Breaches.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
Zero trust networking and the SolarWinds Malware
I explain things like networking, ports, and protocols in that chapter and how malware “calls home” in that chapter. This point at which malware calls home is the point where you might be able to potentially block or identify malware in your network. In the case of SolarWinds, the software first downloaded updates from the SolarWinds update server. After a some time, it attempted to communicate with an attacker-controlled host which sent additional commands to the malware.
The SolarWinds hack demonstrates how a zero trust network could help prevent some data breaches. If the hosts infected by the SolarWinds malware could not communicate with any other hosts on the Internet except those that it absolutely required to retrieve software updates, the malware would not have access to communicate with the C2 server.
Not only would access to the C2 server be blocked by a zero trust networking strategy, it could help an organization identify a breach. Why would a host ever be trying to access something blocked by a firewall rule? Monitoring for unexpected rejected traffic could identify potential malware or at a minimum a misconfiguration that requires investigation.
The problem with vendor software updates
So why doesn’t everyone lock down their networks to only communicate with specific servers for software updates? Many vendors do not provide a specific range of IP addresses, ports, and protocols for the retrieval of software updates or perform application functions that need Internet access. That presents a problem for organizations that want to implement zero trust networking.
Without network specifications including ports, protocols, and IP ranges for software updates, system and network administrators must leave their networks wide open. They need the system to get software updates and they don’t know what rules to create to allow the updates. I found a list of ports SolarWinds requires here, but no domain names or IP addresses for software updates. I didn’t look very hard but a simple Google search should turn up this information quickly if it exists.
Sometimes vendors provide domain names instead of IP addresses for software updates. This doesn’t help if the network firewall you use doesn’t support domain name entries. Azure network security groups and AWS security groups require an IP range (CIDR block). Azure Firewall allows fully qualified domain names (FQDNs), but it is not applicable to a single host. It seems more appropriate to use Network Security Groups, if you can, for zero trust network implementation in Azure.
Why Zero Trust Networking is Hard
Security professionals, software developers, IT staff, and network professionals are probably going to complain right about now that implementing zero trust networking is very hard. It is. Have you ever considered why?
It’s because vendors and software developers do not provide you the information you need to do it. They also do not architect their products with security in mind to minimize network connection endpoints required to run their products. They require you to open so many ports and connect to so many different endpoints it turns your network into Swiss cheese.
Is it possible to minimize network connections required by software products? Yes. I’ve done it. When I created a SAAS platform for firewall products I took this into consideration. Instead of creating separate network connections for every service from our IOT devices to our AWS cloud endpoints we used a single connection and used the MQTT protocol to send messages with different topics that got directed to the appropriate service after it hit our cloud environment. Architectures can leverage proxies, API gateways, and other constructs to minimize the number of different rules that must be configured in firewalls to support a zero trust configuration.
Some vendors may want to use DNS records in case IP addresses change. That is a valid concern. However, Amazon has figured out a way to provide a dynamic list of IP addresses for AWS cloud endpoints and other vendors can too. Customers can write code to dynamically update firewall rules based on the AWS IP ranges available in JSON format. Perhaps this should become an industry-standard requirement and format.
The next time you are evaluating a product to deploy on your network, remember to check how many network connections that product requires you to open on your network. Ask them for the network specifications for firewall rules you need to create to allow the host running that product to get software updates and function properly. This is most important for any host that has user accounts or application permissions that can perform administrative actions in your environment, or connect to and potentially compromise other hosts that have administrative privileges.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2021
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab