By Gregory Hale
While Microsoft is playing down the seriousness of attackers getting in and viewing its source code, surely some red flags are rising as a result of the incident.
Yes, its source code was not altered, and that is a good thing, but could the hackers have copied it to the point of maybe altering it down the road and employing another supply chain-type attack and introducing it in another similar type of assault? Sound far fetched? Hmmm.
“We detected unusual activity with a small number of internal accounts and upon review, we discovered one account had been used to view source code in a number of source code repositories,” Microsoft’s Security Response Center wrote in a blog post Thursday. “The account did not have permissions to modify any code or engineering systems and our investigation further confirmed no changes were made. These accounts were investigated and remediated.”
This revelation comes on the heels of the SolarWinds attack where the company suffered a supply chain attack where hackers inserted malware into a service that provided software updates for SolarWinds Orion platform, which is a suite of products used across a wide swath of organizations from the manufacturing industry to the government and other key sectors, to monitor the health of their IT networks. SolarWinds said 33,000 of its customers were Orion customers, and 18,000 of them may have the product that contained the malicious code.
“As we previously reported, we detected malicious SolarWinds applications in our environment, which we isolated and removed,” said the Microsoft’s Security Response Center post. “Having investigated further, we can now report that we have not found evidence of the common TTPs (tools, techniques and procedures) related to the abuse of forged SAML tokens against our corporate domains.”
Along the lines of attackers viewing Microsoft code, researchers went on to say, “at Microsoft, we have an inner source approach – the use of open source software development best practices and an open source-like culture – to making source code viewable within Microsoft. This means we do not rely on the secrecy of source code for the security of products, and our threat models assume that attackers have knowledge of source code. So viewing source code isn’t tied to elevation of risk.”
“The SolarWinds and related source breaches are Microsoft are the security industries worst case scenario,” said Mark Shavlik, chief executive at Senserva in St. Paul, MN. “Security products need to run with a higher level of permissions and when breached they have the opposite effect of helping with security.
All products are at this risk, security products are no different. Even with full due care there are just too many ways in at some point something bad will happen. That said, we all must up our game around security training and monitoring for our development environments. But beyond that we need to design security products in new ways to lessen the risk of a breach and the impact when a breach occurs“
While Microsoft said they found no evidence of attackers using Microsoft products to attack others, a skeptical person could say while the code is safe, attackers could have a version of it and apply an altered version on their own down the road.
While Microsoft in its post did not name the origin of the attackers, government officials have stated Russia was behind the attack.
While it is nice to know who was behind the attacks, and for global political ramifications, that is important, but for private sector companies, a strong cohesive defense-in-depth program is imperative to keep operations up and running.
To avoid the types of SolarWinds-type of attacks, the following are some best practices for industrial users to employ:
- People need to look at how can they build reliable whitelists. Stop just looking for malware and looking for vulnerabilities, but create a real-time whitelist on what should be running on control systems.
- Network segmentation: Organizations should properly secure the security architectures they deploy. IEC/ISA 62443 offers the basis for this design through the creation of security zones and conduits.
- Establish strict least privilege policies for flows within and between these zones and conduits.
- Accountability: Vendors are not keeping a complete eye on the product once it gains approval. Vendors check for vulnerabilities, but not malicious code.
- More checkpoints when software releases. It is not good enough that developers are doing the checks, there has to be other checks after compiling the software and putting it up on the server.