Contact Us
0 Results Found
              Back To Results
                Close Contact Us
                Business Imperatives

                To Secure the Cyber Supply Chain, Go Beyond Software Updates

                Top 5 Findings from Secureworks’ Proactive Incident Response Engagements, Part 4 By: Donald Allison

                The Secureworks ® Incident Response proactive consulting practice develops incident response (IR) plans, performs IR plan gap analyses, and facilitates tabletop exercises featuring various security risks to the more than 4,000 customers in our base. Over time we have analyzed findings from each engagement, and the patterns that emerge show consistent challenges to organizational security posture and response capabilities.

                This 5-part blog series details the top 5 challenges we see when we’re called in to do a proactive incident response engagement. As these are systemic, widespread issues, we want to raise awareness and share our guidance to help your organization get ahead of them. 

                The first blog in this series looked at what should be considered the basic foundation of any security practice: the definition of “incident.” Click here to read part 1.

                The second in this series discussed another relatively simple item: the contact list. Click here to read part 2.

                The third in this series explored what few organizations do well: data governance. Click here to read part 3.

                This fourth in the series turns to another issue that may not seem as technical: third parties, or alternatively, the “cyber supply chain.”

                This supply chain is not your father’s supply chain. It has been updated a bit and includes legacy code, open source code, and third party software..The cybersecurity world has been abuzz with supply chain wisdom ever since notpetya in 2017. Russian military hackers broke into the Linkos Group company’s update servers for M.E.Doc to create a hidden back door into the PCs where that product was in use. As outlined in this Wired Magazine article, that situation did not end well for many organizations.

                Today the cyber supply chain encompasses far more than just software updates from hopefully “trusted” parties. Legacy code is embedded on large portions of your environments. As the events have unfolded over the past few years, a lot of that code contains potential problems. For example, SMB version 1 is still running in environments. Microsoft upgraded to SMBv2 and other protocols in 2007, and publicly deprecated it in 2014 to address vulnerabilities in the old code.1

                Open source software has its own issues. Open source software needs to be maintained similar to commercial software. Not all software will push out updates and patches after vulnerabilities are identified and fixed. Organizations need to understand all of the software used in their environments and manage it accordingly. For example, Apache Struts released a patch for a vulnerability in March 2017. Unfortunately, as reported in this Ars Technica article, the Equifax hack targeting the patched flaw in Struts took place about 2 months after that patch was released. Tracking, patching, or providing compensating controls of the vulnerabilities in open source products in use in your environment is essential.

                If you have awareness of all of the potential third party software you use in your environment, then you will be the first we have encountered (and please let us know – it would make for a great case study!). For this type of software-related third party/supply chain, it is best to be aware of issues as they are discovered and do your best to patch or apply sufficient compensating controls. But let’s move past software.

                Do you use cloud vendors or other third parties to provide parts of your infrastructure? These third parties bring about contractual limitations on what may be done regarding security and actions during any incidents. Shared responsibility models are standard in provider arrangements, including AWS. However, the gaps in this type of model provide the potential for incidents which may have significant impact. As long as you build in more compensating controls and open up as much monitoring of your accounts as possible, you will have a good start.

                But wait, there’s more. If your organization has partners, contractors, vendors, and others that are allowed in your environment, controls must be set on the levels of access each have. (If you haven’t yet, go back and read about data governance in part 3.) If you have operational networks running automation, sensors, IOT, or other equipment, you must really be aware of how the third parties are conducting themselves in your environment. What if you are a third party in someone else’s environment?

                Segmentation, access controls, lots of monitoring, and most important of them all: contracts. After all, in order to assure everyone is following the rules laid down, contractual language must be clear as to what those rules are, and the remedies should the rules not be followed.

                From a technical standpoint, there should be more than enough information that you can provide to the business and legal functions to aid in developing those contractual requirements, and you should receive information back on the current state of contractual affairs. In addition, if called for, data preservation requirements should be discussed and documented to ensure you have the evidence to show what was or was not done should an issue arise.

                Supply chains continue to be a target of cyber threats today, but by expanding your security approach to include the technical, process and legal considerations above, you’ll be on the right path to resilience.

                If this did not take you too far out of your technical comfort zone, the last installation in this series – business risk - should be a breeze. Stay tuned.

                Such content herein is provided “as is where is,” and Secureworks makes no representations or warranties about the accuracy or completeness of the content contained herein.  Additionally, although the content set forth in this blog may discuss or relate to legal issues, SecureWorks does not provide legal advice or services, and none of such content shall be deemed, construed as or constitute legal advice. You are ultimately responsible for retaining your own legal counsel to provide legal advice. Furthermore, this content shall not be deemed to be legal opinion and may not and should not be relied upon as proof, evidence or any guarantee or assurance as to you for legal or regulatory compliance.

                Related Content