The recent ban on Kaspersky security software is a reminder that we all need to review the source and coding processes of all software used in our organizations, and not just those with a government mandate.
Do you know where the software is coded up? Who maintains the code? Is there any chance that malicious actors could have injected something into your applications?
The answer to that last question is most decidedly yes, considering how the Solarwinds attacks unfolded. While those backdoor attacks were discovered by a firm that specializes in cybersecurity investigation, everyone should be taking the time to review the typical software found in an organization and take a really close look at who produces its code.
Microsoft itself uses programmers from around the world
At the top of the stack is the elephant in the room better known as the Windows operating system. It is the network foundation and backbone of most of the world’s industries. But it’s also a collection of code that has been built over time and by a host of programmers from around the world.
Its security features often come from teams located in Israel, while cloud offerings come from team members in India. And indeed, as discussed during a heated discussion with US lawmakers on Capitol Hill, it was pointed out that Microsoft has employees in China and their goals couldn’t necessarily be guaranteed to align with those of Microsoft.
Microsoft itself already makes changes to its operating system to comply with various export rules and regulations. If you are a multinational business, you are probably well aware of restrictions that govern the use of technology in different countries. High on the list is Trusted Platform Module (TPM) chip and encryption technology whose export to several countries is limited or blocked.
At one time, Microsoft created a custom version of Windows 10 in order to comply with and respond to the Chinese government’s concerns. There were rumors that Microsoft was slowly moving AI researchers out of China to Canada, but it’s unclear if that is what is truly going on.
Almost every device has software at its core
But what about the other technologies and hardware that you have in your firm? From switches to routers, to Wi-Fi adapters, all devices have software at their core. Reach out to your vendors and review where their key coders and support personnel are located. Ensure that your firm has an approved hardware list and approval process in place to securely procure and deploy software throughout your organization.
In this day and age of ransomware attacks, I’d argue the only key tool you have to ensure that there aren’t stealth attackers lying at wait in your network is to review for unusual outbound internet traffic. Ensure you’ve installed additional software on both your Windows and Linux assets to assist you in investigating unusual traffic. For Windows assets in particular, Sysmon for Windows is specifically designed to monitor for process creations, network connections, and changes to file creation times.
Microsoft is also porting many other Sysinternal utilities over to Linux and Sysmon for Linux brings the open-source impact. The open-source nature of the porting project means that you can do a deep code review of what you are installing on your Linux assets. Make sure that you have logging enabled and are storing the logs in a manner that you can analyze the traffic should the need arise.
Watch hardware that contains code just as closely
For hardware that includes code ensure that the traffic you expect to be leaving your network is what you expect. While it’s not an easy task, to obtain an extremely secure network you should limit outbound traffic to only those ports, sites, and access that you have explicitly authorized. While this may be difficult to accomplish in the era of cloud services, it’s not impossible.
Firstly, review how your Azure cloud services are set up and what networking processes you are using. Then keep an eye out for anomalies. Office applications shouldn’t spawn or pivot to opening a shell such as cmd.exe or powershell.exe.
Look for system files that are in locations in which they don’t belong. Also, look for renamed tool files that have been placed in file locations. You’ll want to do hash value scans to confirm file integrity. In reviewing traffic on your firewall, review for unusual file downloads from suspicious domains.
Ensure you are monitoring events that may point to unusual activity. Microsoft has a listing of events they recommend that you monitor.
As they note: “A potential criticality of High means that one occurrence of the event should be investigated. Potential criticality of Medium or Low means that these events should only be investigated if they occur unexpectedly or in numbers that significantly exceed the expected baseline in a measured period of time.”
Microsoft says all organizations should test these recommendations in the environments in which they are used before creating alerts that will trigger mandatory investigation because “every environment is different, and some of the events ranked with a potential criticality of High may occur due to other harmless events.”
Watch for vulnerabilities that service tags can facilitate
In the case of Azure, if you’ve used service tags to set Azure firewall rules, be aware that Tenable has noted that there is a new methodology that attackers are using to abuse users. Researchers at the company discovered a vulnerability in Azure that allows an attacker to bypass firewall rules based on Azure Service Tags by forging requests from trusted services.
“Customers who rely on these firewall rules for security are at risk from this vulnerability,” Tenable wrote in its blog. “They should take immediate action to mitigate the issue and ensure they are protected by robust layers of authentication and authorization.”
It should be noted that Microsoft responded to the Tenable discovery that we should not rely only on service tags as the means to provide protection for cloud assets.
“Service Tags are not sufficient to secure traffic to a customer’s origin without considering the nature of the service and the traffic it may send,” Microsoft said. “It is always the best practice to implement authentication/authorization for traffic rather than relying on firewall rules alone.”
Various services were identified as being impacted by these settings:
- Azure Application Insights
- Azure DevOps
- Azure Machine Learning
- Azure Logic Apps
- Azure Container Registry
- Azure Load Testing
- Azure API Management
- Azure Data Factory
- Azure Action Group
- Azure AI Video Indexer
- Azure Chaos Studio
The common denominator in these various scenarios is this dangerous combination: a service that has an associated service tag and also allows users to control server-side requests.
Microsoft recommends that your public assets should ensure that you have authentication and authorization layers. Tenable notes that “by ensuring that strong network authentication is maintained, users can defend themselves with an additional and crucial layer of security. In that case, even an attacker leveraging the vulnerability to reach the target endpoint would have great trouble exploiting that access.”
Get the idea that being able to trust your code and verify is not an easy task? It’s no different than keeping an eye out for intrusions into your network. Review your current resources and see if you are doing what is necessary to ensure you know your software is written by whom you expect it to be and performs what you expect it to do.