My father spent many years serving in the United States Marine Corps and intelligence agencies. Although he was a loving father, his past made it difficult for him to trust or take information at face value. While this was apparent in everyday life, it was most evident when my sister started dating. When my sister brought home a new boyfriend, the running joke was to allude to any number of humorous scenes from Meet the Parents, a comedy co-starring Robert DeNiro as Jack Byrnes, an ex-CIA agent intent on investigating his future son-in-law.
This common theme of parents wanting to protect their children is the same mindset we should have with the software we use every day in our corporate networks. These networks are our “babies” and it’s imperative we understand the risk of “who we let them hang out with.” An effective way to determine this risk is by using product security testing.
Product Security Testing
Product security testing is like using a lie detector to interrogate a piece of software. It takes a “hostile” or offensive approach to determine the risk to a “loved one,” i.e., our organization’s internal assets.
Over the past three years, there has been a 742% annual increase in software supply chain attacks. A supply chain attack is when threat actors leverage security vulnerabilities within third-party, open-source, or commercial software to attack our networks. While it’s easy for end users to point fingers and blame vendors, this is like blaming the boyfriend’s parents. Organizations often haven't done their part to assess what could go wrong and provide factual data as an early warning to our “loved ones.” The SANS Institute course SEC568: Combating Supply Chain Attacks with Product Security Testing provides you and your cyber practitioners the “interrogation” skills needed to determine software’s risks. This provides the insights required to implement the correct mitigations that will reduce or sometimes eliminate a threat.
Dependencies
Let’s look at a specific example. One of the main topics discussed in SEC568 directly related to the software supply chain, is dependencies. During day five of the course labs, we come across a Windows dependency of a third-party library named “Office2010.dll” which is produced by a company called “Codejock.” We can obtain this information easily by looking at the DLL’s metadata in the property window on Windows as seen in Figure 1.
This dependency is likely not identifiable without conducting more in-depth product security testing. Additionally, it’s likely not a known, commonplace name. If tomorrow, the SANS Internet Storm Center reported a breach of Codejock, would you pay attention? While awareness is a large part of the battle, it often isn’t enough. By continuing our basic online research, the researcher can find an effective mitigation to implement to prevent a supply chain attack for this specific product.
By using the metadata from Figure 1 and cross-referencing the vendor’s release notes from their website in Figure 2, we discover this product dependency hasn’t been updated since 2011. While this may not be the best practice for overall security, it is fantastic for our ability to take a proactive step toward preventing a supply chain attack. By hashing this file, an alert can be created in our organizational security products. If the “Office2010.dll” hasn’t changed in approximately the last 12 years and suddenly it does, that is something we want to know about. This type of alert can be easily created and monitored by your organization’s SOC team using file monitoring tools like Sysmon and EDR solutions coupled with SIEM-like capabilities. The likelihood of a false positive or alert fatigue is low since our research tells us this file doesn’t regularly change.
This is just one simple example of how a few product security testing techniques can reduce the risk and impact of a supply chain attack on your organization. In SEC568, we take these concepts much further and discuss technical techniques such as unpacking firmware, dissecting proprietary protocols, and binary code analysis across multiple platforms such as Android, Linux, and Windows to prepare you and your team for real-world situations.
While this example is simple and easy to relate to, it may also spark questions about the feasibility of conducting product security testing in your organization. Businesses use many different pieces of software and devices, and realistically, they don’t have the time or resources to perform the level of analysis being discussed. My dad couldn’t interview every boy my sister talked to and worked and went to school with. It wasn’t reasonable. But he took the time to do the “testing” on the few that made it to the front door. Why? Simply put, they posed the biggest threat.
When to Conduct Full Product Security Testing
In SEC568, we also discuss when it does and does not make sense to perform a full product security test event and how to use data to prioritize your targets. One consideration is to look at business-critical applications that have high-privileged network access. These types of software and appliances are more likely to warrant a full test versus a piece of software that sits in a segregated non-production network.
How do we slow the increase of software supply chain attacks? We make them less effective for threat actors. To do this, we must be able to deploy product-specific mitigations that reduce the risk of compromise or impact. Product security testing is an effective way to gain the technical knowledge required to determine and then deploy these mitigations. Like Jake Byrnes from Meet the Parents, we must first consider every product and device “outside of the circle of trust” and interrogate them before allowing them to come into contact with our most valued assets.
