Advanced Persistent Threats Are the New Danger

The evidence surrounding SolarWinds and how the attackers used sophisticated means to perform the attack is mounting, with the discovery that a third identified malware was used in the attack. Named Sunspot, this malware was used in addition to the Sunburst and Teardrop malware already identified. It is believed that the Sunspot exploit was the first used in the chain. Amazingly, cybersecurity firm CrowdStrike released information that this malware was first deployed way back in September 2019 when the SolarWinds network was first breached.

It appears that the attackers planted the Sunspot on the build server for SolarWinds, which was used to construct the software and build the applications they sold. Sunspot was designed to do one thing: Observe the build server and watch for commands to assemble the Orion software—the one that was ultimately exploited—which was their top product with more than 30,000 customers globally. It's pretty incredible, as it's been implied that the hackers performed research on the top product they wanted to use for a broader attack, because SolarWinds was a means to an end, not the final target. They installed it and let it run for a long time, meaning they were willing to wait for it to achieve their ultimate goal—gaining access to tens of thousands of SolarWinds customer networks.

It gets even more intriguing as it is observed what the Sunspot malware did: When a build command was sent to the build server for the Orion application, it stealthily pulled out the legitimate code and replaced it with the code the attackers created, which included the Sunburst malware. This meant the source code was altered and not even the developers were aware. The infected code then was uploaded to the official SolarWinds update servers for customers to download, which unwittingly opened their networks up to data theft and damage.

When the malware‐infected Orion software was downloaded and installed at the customers' networks (e.g., governments, organizations, companies), it collected data and sent it back to the attackers via command and control servers (C&C). (The technique used was not common but had been previously used by APT teams.) The C&C used DNS communications to hide under the radar of the monitoring tools. Orion used a domain generation algorithm (DGA) to create domain names to contact. DGAs are algorithms used in many forms of malware that periodically generate a large number of domain names, which are used as drop‐off locations for the C&C servers. The huge number of drop‐off locations created by the DGA makes it nearly impossible for any law enforcement or forensics team to determine these locations and shut them down. The attackers even went so far as to use a public‐key encryption to impersonate the hackers because C&C servers will only accept commands from properly signed controllers.

Each infected computer receives a unique ID by the Sunburst malware. This ID is comprised of the MAC (hardware) address, the computer's domain name, and the Windows installation Universally Unique Identifiers (UUID). The ID is then encrypted using an MD5 hash (i.e., an encryption algorithm typically used for digital signatures) and other sophisticated encryption methods. Due to how the communication takes place, the infected computer does not contact the C&C servers directly but goes over normal DNS traffic until it lands at the hacker's DNS server. The payload includes the domain name of the infected company and the information found on the compromised computer.

The communications to the C&C also includes information about any security software running on the computer. The malware would look to determine if any of the CrowdStrike, Carbon Black, FireEye, ESET, F‐Secure, or Microsoft Defender tools were present, operating, stopped, or disabled. Based upon this information, the software then decides whether to stop the attack or to deploy another communication channel. The attackers then decide, based upon the information collected, whether the victim is worthy of the next step: deployment of the Teardrop backdoor trojan. For those instances where the victim was deemed unimportant or too high a risk, the Sunburst malware was instructed to remove itself from the network.

Further evidence now indicates that the attackers made a test run. From September to November 2019, the Orion product contained changes in it from the hackers, who were just seeing if they could insert malicious code into their builds without detection. As companies and governments continue to admit to being victims of the hack, more revelations will continue. One mystery that still remains is how the hackers gained access to the SolarWinds network in the first place. Was it a phishing campaign, exposed credentials, or some other method?

This detailed explanation of the SolarWinds timeline and methodology of the attackers is a new chapter in Cybersecurity Third‐Party Risk. Along with the others previously mentioned (Vietnam, Mongolia, and so on), it shows how patient but focused these attackers are to get to their ultimate victims. These exploits highlight the numerous gaps that can be found in our security for third‐party software and our detection capabilities; and they reveal how non‐critical software can be exploited, and how even security experts and firms can be hacked as well. The names of those caught up in the SolarWinds attack are not small‐time organizations, but ones with good defense‐in‐depth and security practices.

These advanced threats are not going to dry up when the pandemic is over and life returns to a new normal. The SolarWinds attackers started well before anyone heard of COVID and are unrelated to the risks that it posed. Similar to the state attacks in Vietnam, Mongolia, and elsewhere, these attacks did not leverage the confusion and fear over the flu, but weaknesses in the supply chain. They will continue and more likely grow in their spread and sophistication. What is amazing right now is that of the 30,000+ customers that used the Orion product, so few have publicly disclosed the hack. The attackers actually tailored their product to avoid detection, to erase copies of unneeded malware, and to avoid targets that were viewed as well protected with popular antivirus or malware solutions.

The APT attackers have already figured out how to exploit the weakness at a time when the Third‐Party Risk Management (TPRM) and Cybersecurity Third‐Party Risk practices are still unprepared for this new threat. Organizations have an obligation to their customers and employees to protect their data, which can only be accomplished by developing, activating, managing, and testing a Third‐Party Risk Management and Cybersecurity Third‐Party Risk team that meets this new challenge and the existing threats.

Cybersecurity Third‐Party Risk

Cybersecurity Third‐Party Risk is not practiced enough, and statistics show that of those who perform it, they are not performing it enough. This gap has increased as organizations continue to ignore, or not pay enough attention to, their supply‐chain security, and the cybercriminals and APTs are exploiting them in ever more crafty and dangerous ways. The recent exploits are a “call to arms” for organizations to not only pay attention to their own internal cybersecurity, but to treat supplier security with equal energy and resources.

Organizations lacking a TPRM program should start by creating a program and governance immediately. The frameworks are freely available and can be used as great starting points. In addition, several industry organizations can provide peer guidance and documentation to anyone who joins. Do a quick internet search on TPRM and you will get more than a few results. Start by making an inventory of your vendors, then identify those with sensitive data or a connection to your network. Create policies and standards for how third parties can conduct business with your organization. Identify leaders for each of the risk domains appropriate for your company and have them create questions and requirements for each of them.

Build a mature enterprise‐wide TRPM program. Many approach it as a silo, where each business manages its own vendor pool. This compartmentalized approach, however, leads to several increased risks. First, when a single business unit decides to accept a risk, it is oftentimes accepting that risk for the whole company. If a breach occurs on the sales database at the vendor, the news and potential litigants will not blame the sales team or the vendor. It falls on the shoulders of the whole company to rectify the bad press and to pay for costs to make customers whole again. Second, the silo approach means the organization likely has multiple standards (if any) for vendor requirements and due diligence efforts. Allowing multiple standards provides zero clarity at the executive leadership level about risk across the entire organization.

Creating an enterprise TPRM reduces this risk of a non‐standard unified approach to third‐party risk. A steady well‐defined process for a vendor's intake, ongoing, and offboarding assessments benefits both the company and the vendors. The requirement to have suppliers go through a centrally managed process ensures consistency and the ability to provide a holistic view to company leadership of overall risk. TPRM and cybersecurity organizations have a lot in common—they exist to identify and reduce risk. These two teams have a common goal and with that, a singular focus. They just need to bridge the gap between them for a more direct and complete picture of the cybersecurity risks that third parties pose.

If you are a public company with a Board of Directors or a sole proprietorship, the tone of taking vendor risk seriously starts at the top. Senior management in all forms needs to be educated because they are ultimately the ones responsible to shareholders, customers, and employees for third‐party risk. There must be a culture of transparency and accountability for how vendor relationships are screened, onboarded, monitored, and offboarded. Leadership must present a policy or standard statement that sets the tone and tenor for taking on vendor relationships as a risk that must be managed and reported. Leadership at a company can change a culture from one of compliance or complacency to an active threat‐hunting mode that will lower risk from third parties.

Always take a risk‐based approach. Most companies have hundreds or thousands of third parties that pose a risk to them. While the scope of vendors means they all need due diligence, focusing on those with the higher risk means resources know where to focus their energies. Create tiers or levels for suppliers to be placed in according to the risk they present; using a quantitative approach by number of records is an easy way and can lead to discussions about cyberliability coverage levels as well. These risk levels are used to determine how often a vendor should have assessments performed, the level and depth of questions in the assessments, and whether additional steps are needed to validate their security.

A risk‐based approach also must to be taken into context when deciding which due diligence activities, monitoring software, staffing, and other resource considerations to consider. Just as in securing the internal corporate network, a cybersecurity team and corporate leadership will not always deploy every solution, software, and infinite resources; this is similar in the third‐party risk area. Being risk‐based means observing, calculating, and weighing the risk against the countermeasures or costs of mitigation. Not every solution can be deployed or should be used, but the ones that work for your organization at the levels required for your risk appetite are the most appropriate.

Conversations with third parties are crucial to the partnership needed to reduce their cybersecurity risk. Because many organizations view the third‐party risk as a compliance or checkbox activity, their efforts are focused on sending out questionnaires and checklists for vendors to fill out attesting to their controls. These remote assessments can be useful, but a checklist will not produce a view of how the vendor's security is implemented holistically. Conversations with vendors, whether via a video‐conferencing tool or in person, involves eye‐to‐eye contact and is valuable as a way to build trust and transparency.

On‐site assessments are the best option for determining the actual security controls in production at a vendor. Remote and other assessments are where the supplier describes what they view as their state of infosec controls. It's the equivalent of asking your kids the state of their room's cleanliness. We've all been children or had children and know that their definition of “clean” is almost never the same as the parents' definition. An on‐site assessment allows an analyst to perform a physical validation of security controls by looking at a vendor's policies and procedures, then having them demonstrate they are followed in production and practice. When parents go to their kids' rooms in our example, it offers a direct view of the items under the bed and the closet stuffed with all the toys and dirty clothes.

Concentrate your company's attention on closing risks and findings. All the due diligence activities are important in discovering security gaps at third parties. However, the end goal should be focused on remediation and closing up these gaps. A Cybersecurity Third‐Party Risk team that takes ownership of these identified gaps and drives them to closure with the vendor is one that is bringing the purpose of their team to fulfillment—reducing risk.

Focus on cybersecurity risk with your vendors. While there are other risk domains in Third‐Party Risk Management, the evidence and trends clearly demonstrate a need to “beef up” the security space. The other risk domains are not to be ignored, but the financial, reputational, and physical risks from a cybersecurity incident far outweigh any recent or historical cost of another risk domain being breached. This means having appropriate levels of staffing and expertise in the cybersecurity space assigned to or focused on third parties.

Many cybersecurity organizations have staff focused on the company's internal security. These teams specialize in looking for threats and preventing them from hacking into the network. And while some do have a Cybersecurity Third‐Party Risk team, most do not if the polls are accurate. Resources can be a challenge. But in a new TPRM program, it can be as simple as collaborating with cybersecurity leadership to identify the appropriate subject‐matter experts (SMEs) to assist with due diligence efforts. In organizations that are further along in the maturity model, having a Cybersecurity Third‐Party Risk team does not necessarily guarantee success.

Most of these current teams reside inside Governance, Risk, and Compliance (GRC) teams. In regulated industries, Cybersecurity GRC teams are a necessity and there is nothing wrong with them as a practice. The issue often becomes that a Cybersecurity Third‐Party Risk team is viewed as a compliance effort. Compliance and security are not synonymous. Compliance is a checkbox activity to let an auditor or regulator know that your organization obeys the rules. Security is an ongoing activity that never stops and is certainly not a point‐in‐time compliance effort. These teams need to get out of that mentality and become more akin to their cyber peers in threat operations teams who perform ongoing daily investigations into the security of the vendors.

Fourth parties cannot be ignored in any Cybersecurity Third‐Party Risk program either. The processes for intake, ongoing, and offboarding assessments must screen and monitor these critical parts of the supply chain that are too often ignored or not viewed. Require vendors to declare what fourth parties they use to provide the service or product to your company. Place in the legal contracts that they must inform you of any updates or changes to their third‐party relationships so new risk assessments can be performed if necessary. If a supplier is offboarded, do not forget to look at any fourth party that has your data and ensure it is properly destroyed or returned.

A smarter way to perform this oversight on fourth parties is also risk‐based: Enhanced Continuous Monitoring focuses on the vendors who are viewed by business as systemically critical and the cybersecurity team has labeled as high risk. This pool of suppliers will be asked additional questions to provide more transparency on their third parties—your fourth parties—who are necessary to provide the service. Because each vendor can have dozens or more of their own third parties, managing fourth parties across your whole portfolio can become an exponential problem. Focusing on these high‐value, high‐risk vendors and what vendors they use provides a focused risk‐based group that is small enough for a team to manage.

Cloud deployments with vendors are normal and cannot be avoided for most services or applications. The Shared Responsibility Model for the different deployment models (i.e., IaaS, PaaS, and SaaS—Identity, Platform, or Software as a Service) have distinct duties for the vendor and the CSP. Knowing which model a supplier is using with the CSP should drive the control questions asked as well as determine the responses required. The data's location, whether in a CSP, a co‐location, or a vendor data center will require differences in approach as well, as most of the CSPs do not allow a physical security review. Vendor data centers can present some security challenges on the physical side as these are expensive complex environments.

Network connections are a door into your network by a vendor. The lifecycle of a third‐party link must be clearly described in a policy and a process that is automated, lowers the chance of something being missed. Define clear guidance on both the hardware and any out‐of‐band (OOB) communications services that are allowed to be deployed. There are Zero‐Trust (ZT) options for these third parties based upon their type of business or access pattern. Sales partners, integrated support services, and offshore business process outsourcing (BPOs) are some of the examples that were presented. These can be given their own enclaves with the benefit of a repeatable process that provides the correct access limits based upon the use case.

Legal requirements on security controls are critical mechanisms to clarify what your organization holds third parties to and often focuses the vendor on what is important to your security. If the language is in the Master Services Agreement (MSA) or in a separate addendum, the cybersecurity team can provide the specific controls for information security, hosting/cloud, privacy, and offshore controls. Create a list of non‐negotiables that the company views as immutable requirements that protect your data and network. The obvious ones are ensuring data is encrypted at all stages, enforcing multi‐factor authentication (MFA) for privileged accounts, and the ability to perform on‐site assessments for vendors meeting this criteria.

Offshore third parties can bring cost savings and productivity gains to organizations, but they do require special contractual language and due diligence to monitor and control their particular security concerns. Vendors who are remote from the home country can increase challenges for travel and scheduling on‐site assessments; however, these in‐person due diligence efforts are almost obligatory for them. If possible, reduce or prevent the ability for data to move offshore to lower the risk of it becoming subject to another regulatory body. Plan the on‐site assessments and be ready to perform them with an eye toward the physical security controls.

Use technology to your advantage. Lots of options exist to manage the TPRM program and its information through software and technology solutions. These applications can play a critical role in assessments, Continuous Monitoring, management, and reporting of risk. Centralizing the information in a database offers streamlined improvements for due diligence efforts, audits, compliance reporting, and ongoing performance oversight. Leverage workflow automation to ensure that people do not drop the ball. Either the TPRM software can contain this automation, or another tool that can interface via API to perform the workflow.

Some more advanced tools also exist that can consolidate and manage the third‐party risk information and intelligence for risk‐based decision‐making. This reporting can be created on your own with a database and a business intelligence or analytics tool, or the software can be bought and customized from one of the makers of these more advanced software applications. These solutions can identify high‐risk vendors and provide risk impact and likelihood, risk rankings, and vendor controls that are found insufficient or suspect. Leverage these tools to open communications about “Red Vendors” and ways to shape their behavior by lowering their risk with the help of business sponsors.

Test and validate your program periodically. There should be at least an annual validation of the program by another internal independent team or an outside entity. These assessments of the effectiveness of the program should start with looking at the policies, standards, and procedures that are published and followed by the internal teams. These audits then take random samples from the due diligence, monitoring, third‐party incidents, and other activities to ensure that the steps are followed and provide the value expected. When gaps are found between policy and practice, they need to be documented, discussed, and remediated as soon as possible. This feedback into the program helps build a more mature and effective TRPM program.

Develop a reporting program and provide updates to the stakeholders and executive leadership to foster more transparency of vendor risk and ownership within the business and to help lower that risk by making different choices or pressuring current vendors to remediate gaps. The data from due diligence efforts, ongoing monitoring, Continuous Monitoring, connectivity, and other items can be rolled up in a database or with TPRM software tools. Teams can then create Key Performance/Risk Indicators (KPI/KRIs) to track the risk appetite using the data being produced. The number of third‐party breaches, amount of past‐due high‐risk findings awaiting remediation, and other KPI/KRIs are important for the Cybersecurity Third‐Party Risk team to drive vendors to remediation and as a flag for executive leadership indicating potential high risks as the triggers surpass preset thresholds.

More mature programs can expand their abilities by leveraging all the data collected (internally and externally) to start a more predictive, risk‐based focus on their third parties. Most of the TPRM programs—in particular, the cybersecurity teams—are fairly reactive in their work. A third party notifies them of a breach, a security assessment finds a gap or two or more, or the CM program throws an alert. The next step is to use all this data to begin making more deliberative decisions based upon all available information for those vendor(s).

Create some thresholds and triggers, along with how to provide a weight to each of the inputs. Not all data is created equally: An on‐site assessment is more reliable than a remote one, and information retrieved from internal systems of record can be more dependable than external feeds. The dashboards that these systems can create will provide more transparency to executives but also can give the cybersecurity team a chance to become more predictive in their approach to vendors. When a third party has been trending toward a more “Red” category, it's different than waiting for an alert. Analytics and BI software offer an opportunity to get out of the current reflexive response into a model where third parties that are on a negative trajectory can be engaged with earlier.

Cybersecurity Third‐Party Risk and Third‐Party Risk Management are both professions and practices with solid frameworks, industry best‐practices published, and adequate certification paths for adherents, in addition to all the other software, tools, and technology available to produce successful programs. There has been a lack of attention in some cybersecurity teams to the risks posed by third parties, and some TPRM groups have not sufficiently paid attention to the risks of cybersecurity. Much of the focus in regulated industries has been on compliance and not on treating them as a security activity. While TPRM and Cybersecurity need to grow their maturity individually, they need to increase their collaboration to mature cybersecurity third party risk as a whole. This collaboration will lower the risk posed by Advanced Persistent Threat actors to your data and networks.