Old modems, routers, network equipment. Serial, phone, audio, ethernet connectors.
Security Operations

Digital Detritus: The engine of Pacific Rim and a call to the industry for action

Decades of obsolete and unpatched hardware and software endanger us all

At the heart of the Pacific Rim attacks against Sophos’ firewall software lies the digital equivalent of the ocean’s own Great Pacific Trash Vortex, an immense but nearly invisible mass of deteriorating material – in this case, obsolete and/or unpatched hardware and software. Akin to the Trash Vortex on earth or space junk above it, this ever-expanding digital detritus has dire consequences. This essay examines the situation and presents my thoughts on how the industry can tackle the problem.

  1. Introduction
  2. Accepted truths and Digital Detritus
  3. Cleaning up our future
  4. Stepping up today: Call to action
  5. Conclusion

Introduction

In a series of public keynotes through 2024, Jen Easterly, the director of the United States of America’s Cybersecurity and Infrastructure Security Agency (CISA), declared to the industry that “we don’t have a cybersecurity problem, we have a software quality problem.” She further highlighted that today’s multi-billion-dollar cybersecurity industry exists because technology companies in all industries, sectors, and market segments have been permitted to ship and deploy software with exploitable defects. CISA is working to shift market attitudes from “software defects are an inevitable part of life” to “some classes of defects are unforgivable” through their Secure by Design initiative for technology vendors, and its counterpart, Secure by Demand for technology buyers.

The rationale is economically sound: the best way to incentivize technology vendors to invest in building and maintaining secure software is to encourage customers to vote with their procurement dollars. The efforts are an important early step in moving the industry toward what Easterly has described as a “software liability regime, one with an articulable standard of care, and one with Safe Harbor provisions for those technology vendors that innovate responsibly by prioritizing secure development processes.”

I open this article with a brief summary of CISA’s work because I believe these efforts have been a crucial missing ingredient to the improvement of the state of cybersecurity. It is no exaggeration to say that improvement is a matter of great importance to our economy, our national security, and the welfare of our nations’ citizens worldwide. This article is a companion piece to a Sophos post titled “Pacific Rim: Inside the Counter-Offensive—The TTPs Used to Neutralize China-Based Threats,” which documents our multi-year battle with Chinese nation-state threat actors who were making every effort to exploit defects in our firewall software in an effort to victimize Sophos, our customers, and uninvolved third parties. The accompanying timeline and technical details document the series of decisions, investments, improvements, and innovations that emerged from the engagement.

All of the vulnerabilities described in our Pacific Rim report were previously disclosed and remediated — there are no new or unresolved vulnerability disclosures — but we share the full report with the awareness that we’re drawing attention to our own historical defects, and that there could be adverse market reactions to this level of public transparency. It was a matter of debate for us internally, but I am optimistic that the reactions to the Pacific Rim report will be constructive and mature, will focus on the learnings and the improvements that the chronicled events drove, and will provide an example of the sort of “standard of care” which can emerge from confronting, and eventually defeating, such persistent adversity.

Accepted truths and Digital Detritus

“For some products, it’s just too easy to find vulnerabilities,” begins the 2007 MITRE report titled “Unforgivable Vulnerabilities,” which describes classes of vulnerabilities so seemingly mundane that their occurrence could be considered “unforgivable.” While we might expect such defects from casual software developers, we expect better from the class of vendors who we all rely on to protect us, such as operating system vendors, infrastructure vendors, and cybersecurity vendors.

Somewhat paradoxically, OS vendors occupy top spots on the leaderboard of distinct vulnerabilities, and cybersecurity vendors are far from immune. In an analysis of over 227,000 CVEs performed by Security Scorecard, 12.3%* of them came from cybersecurity vendors, and there have been hundreds of CVEs related to infrastructure. We can begin to untangle and confront the paradox by considering the following five points:

1. Market success predicts exploitation

a. All software that is accessible to attackers will eventually come under attack, with the likelihood of targeting and exploitation increasing along with adoption

b. The larger the footprint the vendor has, the greater the obligation—and cost—to maintain secure software; product budgets and lifecycles often fail to account for this

2. Competition can aggravate moral hazard

a. Poor software quality creates a massive market for cybersecurity products and services. A 2022 report from the Consortium for Information and Software Quality estimated that the cost of poor-quality software in the U.S. alone was at least $2.41 trillion

b. While most software vendors face market competition, the demand for cybersecurity has attracted billions of dollars in venture investment: an estimated $8.5 billion in 2023, and $7.1 billion in the first half of 2024. That’s a 51% increase from the first half of 2023, driving greater market competition and urgency for continuous innovation and differentiation

c. In addition to such market competition, the cybersecurity industry somewhat uniquely faces daily challenges from our real enemy, the adversaries we defend our customers against, requiring even faster reaction times and greater agility

d. These combined forces can adversely lead to the prioritization of features or updates over safe and secure designs and deployments, sometimes causing mass exploitation or disruption at global scales

3. Patching is hard

a. It is well understood how operationally burdensome patching is

b. Patching is a shared responsibility, meaning that the vendor must produce the patch, and the customer (or some other responsible party, such as their service provider) must apply the patch; delays in either increase the chances of exploitation, and an unapplied patch is worthless

c. While as-a-service (*aaS) models simplify the patching challenge by enabling vendors to wholesale repair defects in their hosted environments, there will likely always be an on-prem component that the industry needs to contend with

i. We tend to think of infrastructure (firewalls, remote access-layers such as IPsec or SSL VPN/proxy/ZTNA, email servers, etc.) when we think of on-prem, but the biggest class of on-prem (i.e. customer / service-provider as opposed to vendor owned and managed) is endpoints and their operating systems and applications running locally

ii. Despite the growth in *aaS models for certain elements of security infrastructure (e.g. FWaaS), on-prem remains the dominant network security model for reasons of autonomy, latency, and resiliency (i.e. avoidance of concentrated failures) – according to Gartner, 87.5% of 2024 firewall revenue will be for physical firewalls

iii. Certain infrastructure and operational types currently have no foreseeable path to an *aaS model, e.g. Operational Technologies (OT) and Internet of Things (IoT)

4. Buyers and sellers have misaligned generational incentives

a. Buyers are incentivized to maximize the longevity of their technology investments by getting as much mileage as possible from a generation of technology. In other words, barring any unacceptable functional constraints, buyers will attempt to keep their infrastructure (e.g. firewalls, routers, proxies, etc.) in production for as long as possible before upgrading

i. We may call this “infrastructure inertia” and without some force to counteract it, out-of-date infrastructure tends to build up over time up to the point of some unignorable failure, particularly among those below the cyber poverty line

ii. Unlike certain consumer technologies, such as mobile phones or cars, there is no status or prestige increase associated with the latest infrastructure, robbing it of a motivating force that is commonly associated with higher velocity consumer technology generational turns

b. Sellers are incentivized to maximize generational turns for a number of related reasons: 1) to provide enhanced functionality and improved user experiences, 2) to defend against obsolescence and customer defection, and 3) to increase unit sales

i. Vendors who engage in forms of “planned obsolescence” practices place themselves at a competitive disadvantage to vendors who don’t, and potentially at risk of customer dissatisfaction if actions and schedules are not clearly communicated, even if defensibly in the best interest of the buyer (e.g. in service of improved security, reliability, or functionality)

c. The longer a digital infrastructure remains in place, the more likely it becomes that vendors will fail to provide software updates

i. Vendors all operate with certain boundaries of support for their products, after which time they cease to provide support, new firmware, code updates, or security patches

ii. It is economically infeasible to expect technology vendors to support all generations of hardware, firmware, operating systems, and software “forever,” because cumulative costs would eventually become crushing; a different model for managing lifecycles is needed

5. All vulnerabilities trend toward the unforgiveable over time

a. Even if more mundane vulnerabilities (by precedence, obviousness, simplicity, etc.) are at all times unforgivable, the apex vulnerability, the zero-day, is by contrast somewhat more forgivable when it is first discovered. However, even the dreaded zero-day has a half-life; e.g., WannaCry’s vulnerabilities (CVE-2017-0144 and CVE-2017-0145) were stunningly formidable in 2017, but in 2024 any remaining exposures are mundane and therefore unforgivable

i. Without derailing, it’s worth noting here that there is an analogous problem when it comes to cryptography: today’s strong cryptography grows weak with the advancement of tomorrow’s computing power. The industry is confronting this parallel problem through various quantum-safe initiatives, and there are mutual lessons to be learned; remember that terms like “strong,” “safe,” and “unforgivable” are relative and have a temporal component

I refer to the dynamic of these five points as the Digital Detritus problem. Infrastructure inertia leads to infrastructure dereliction that becomes more dangerous over time, presenting a progressively large, unhygienic, unpredictable, and unmanageable attack surface for adversaries to exploit. It is conceptually very similar to space debris, which describes the complications and dangers we increasingly face in space missions because of the accumulation of derelict objects in orbit from previous missions. Both problems are examples of what economists call negative externalities; that is, prior activities that impose future costs on other parties without being properly reflected in market prices.

Another well-known example of this is pollution, such as the Pacific Ocean Trash Vortex cited earlier. In the case of Digital Detritus, costs are imposed on both the buyer (from increasing risk of attack and disruption, through to organizational extinction events; 60% of small businesses that experience a cyberattack go out of business within six months) and the vendor (e.g. increasing cost of R&D and support, reputational risk, legal exposures, market valuation impacts). They’re also imposed on unwitting third parties who can suffer harms when derelict infrastructure is used in proxied or obfuscated attacks, botnets, supply chain compromises, or other indirect forms of cyber victimization.

* According to an analysis by SecurityScorecard Threat Research, Intelligence, Knowledge, and Engagement Team (STRIKE), security vendors reported 27,926 CVEs of the total of 227,166 as of the time of their analysis.

Cleaning up our future

Over the past decade in cybersecurity, we’ve been fortunate to witness a shift in thinking among organizations from “it won’t happen to me” to “it can happen to any of us.” This healthier attitude isn’t yet pervasive, particularly among those below the cyber poverty line, but it is trending in a positive direction.

Through the combination of the Biden Administration’s 2023 National Cybersecurity Strategy and the efforts of CISA with their Secure by Design and Secure by Demand initiatives, we in the US are at the early stages of shifting vendor thinking from “software defects happen ¯\_(ツ)_/¯” to “let’s shift the burden from those who are least capable (target rich / resource poor) to those who are most capable.” Capability refers not only to financial means, but also those with the most skin in the game, and those with the most expertise. Within the software vendor space, I believe that cybersecurity and operating system vendors carry the greatest obligation and must lead by example. One significant way this is happening is with the Secure by Design pledge. Sophos was a signer during its inaugural event at the RSA Conference in May 2024, and there are now 234 signers so far who have pledged to put their money where their mouth is when it comes to upholding the three core principles of Secure by Design:

1. Take ownership of customer security outcomes – Shifting the seeming “everything must go right” burden from the customer to the vendor. This includes adoption of Secure by Default Practices (elimination of default passwords, field testing, hardening simplification, discouragement of unsafe legacy features, attention-grabbing alerts, secure configuration templates), Secure Development Practices (Secure Software Development Lifecycle (SSDLC) framework conformance, documented cybersecurity performance goals, vulnerability management, responsible open source software use, secure defaults for developers, cultivating an R&D culture of security, testing with real security operations teams, aligning to zero trust architectures), and Pro-Security Business Practices (logging at no extra charge, treating security features like a customer right rather than a luxury good, embracing open standards, providing upgrade tooling). In a commercial sense, this should also mean packaging products that require a lot of expertise to use (e.g. XDR, SIEM) into services that combine the technologies with their optimal operationalization (e.g. MDR, Managed Risk services)

2. Embrace radical transparency and accountability – Rejecting the dated intuition that publishing vulnerability details provides a “roadmap for attackers” or ammunition for ambulance-chasing competitors, and focusing instead on the abundance of benefits. Taking steps toward the publication of levels of detail as Secure by Default Practices (aggregate security statistics and trends, patching statistics, data on unused privileges), Secure Product Development Practices (security controls, threat models, secure development lifecycles, self-attestations, vulnerability disclosure detail, software bills of materials, and vulnerability disclosure policies), and Pro-Security Business Practices (Secure by Design executive sponsorship, secure by design roadmap, memory-safety roadmap, published results) that will move cybersecurity toward the kind of safety advancements that we’ve seen in the automotive industry (CISA’s Bob Lord and Jack Cable cover this in the video here)

3. Lead from the top – Organizational cultures, structures, and incentives that make security a business priority, as can be demonstrated through such actions as Secure by Design inclusions in financial reports, regular reports to a Board of Directors, empowering the Secure by Design executive, creating meaningful internal incentives, creating a Secure by Design council, creating and evolving customer councils

With the exception of cybercriminals, everyone is cheering for CISA’s efforts to succeed, gradually ushering in a more secure future for all of us. But what do we do about the exposures that exist today, and which will linger for some time?

Stepping up today: Call to action

I would like to specifically address what I believe are the obligations of cybersecurity vendors. As mentioned, I believe we must hold operating system, infrastructure, and cybersecurity vendors to a higher standard among all technology vendors, and I believe cybersecurity vendors must lead by example.

Sophos learned a series of lessons through the course of Pacific Rim about building security cultures, ways of thinking about product lifecycles, and, of course, managing security incidents. The organizational, process, product, and tradecraft improvements that we made through the engagement were marked by struggle and won by persistence. We emerged with a set of “dos and don’ts” of owning security outcomes for our customers, which I will summarize.

Let’s begin with a couple of “cybersecurity vendor foundation” assumptions: First, that we have embraced and are actively in stages of operationalizing the three core principles of Secure by Design, summarized above. Second, that we have already signed up to the Secure by Design pledge, and have begun publishing, through such interfaces of transparency as our Trust Center, our progress in each of the seven pillars of the pledge (multi-factor auth, default passwords, reducing entire classes of vulnerabilities, security patches, vulnerability disclosure policy, CVEs, and evidence of intrusion). We had a robust SSDLC, sets of product telemetry, corporate and product security operation, and X-Ops research capability prior to Pacific Rim, enabling us to stay one step ahead of our attackers, but much of our progress toward the now-documented CISA ideals was made as a result of our experience. While experience is the best teacher, studying and following a well-written guide is the more merciful teacher. Please, put it to use.

In addition to my entreaty to align to CISA guidance, let me also share a set of lessons learned through the course of Pacific Rim that both contributed to our navigation of the events, and our betterment coming out the other side of them:

1. Mergers and Acquisitions (M&A)

a. While the Pacific Rim incident was not directly caused by an acquisition, it was rooted in one dating back to 2014. Cybersecurity is a fast-moving industry, with a lot of investment and a lot of consolidation. Sophos has acquired and integrated a total of 14 companies since then, and with each transaction our diligence processes and integration disciplines improve. The two lessons for us here were:

i. In environments that drive continuous improvements, yesterday’s processes might not have been as rigorous as today’s, and it can be worth going back and re-inspecting critical areas through new lenses when improvements are introduced. Specifically, we would have benefited from re-inspection of certain elements of product architecture

ii. When acquiring companies, there is typically some choice in the balance between rapidity of integration (including adoption of standards and processes) and allowing the acquired company to continue to operate undisturbed. This is particularly true when acquired companies have rapidly growing, thriving businesses rather than being earlier-stage technology tuck-ins. We would have benefited from a more rapid integration into our corporate SSDLC practices

2. Invest in programmable telemetry and analytics

a. As is common with most compromise investigations, the process of collecting data was an iterative process, where discoveries in a first tranche inform the need for new data to be collected in the next tranche, etc. At the start of the engagement, we relied on our hotfix facility to programmably collect new data from affected firewalls, and while this was effective, it would take up to 24 hours for the hotfix updates to be applied and the data to be returned. By the time we ended the engagement, we had our Linux EDR agents installed as a standard component of our firewall operating system, and we were able to use it for instantaneous queries and responses

b. Through the course of the engagement, we relied heavily on our ability to accurately determine which of our customers were vulnerable, which had received automated updates through our hotfix facility, which were showing signs of compromise, and which units were in the possession of our adversaries. This allowed us to send targeted communications to our customers and partners through our outreach campaigns, and to closely monitor the actions of our adversaries

3. Invest in operationalizability (o18y)

a. Unapplied patches don’t help to protect customers, and even if a vendor makes a patch available, there is often a significant lag between publication and application. The ability to operationalize an update (o18y) quickly, safely, and non-disruptively, matters as much as the update itself. Having the hotfix capabilities and modular architecture described below as part of our firewall operating systems since 2015 made all the difference in our ability to protect our customers through the engagement

b. Hotfix facilities that allow for critical updates to be applied relatively instantaneously (following safe deployment practices, e.g. full testing, staged rollouts, versioning, etc.) can make the difference between a remediated vulnerability and an exploited vulnerability

c. Modular architectures that allow for code component updates without requiring a full firmware update and a reboot make hotfix facilities possible

4. Your Support and Customer Success organizations can dislodge inertia

a. In-product notifications of the availability of patches or updates are helpful, but they are often insufficient, particularly with infrastructure devices that can go weeks, months, or even years without an administrator logging in if it’s functionally “just working.” This is just another facet of infrastructure inertia, and it requires some force to move it, ideally some force other than perceptible exploitation or failure

b. Although vendor Support organizations are typically thought of as inbound business functions, we leveraged our Support organization to conduct outreach programs to our non-responsive at-risk customers, which significantly reduced the number of unpatched units

c. On a related note, it is important to ensure that you have up-to-date contact information for your customers; good data hygiene is foundational to services like MDR (Managed Detection and Response) where you must regularly communicate with your customers, and it can also help you to reach your product (non-service) customers in the event of an unresolved vulnerability, or if product telemetry, such as a Critical Attack Warning system, predicts an incipient attack

5. Monitor your fleet

a. While there are many active threat actors compromising vulnerable infrastructure globally, the Volt Typhoon threat group is deservedly receiving a lot of attention for their audacious pre-positioning activities. Like inviting a vampire into your home, at its core, the Volt Typhon threat is being invited into victim networks by the Digital Detritus problem, but we cannot solely blame the victims for extending the invitations; it’s a shared responsibility with vendors, and requires vendor collaboration to address

b. As a result of Pacific Rim, we now think of our customers’ deployments of our products as an extension of Sophos, and we monitor the “fleet” of assets as we do our own infrastructure. This is a mindset that we would encourage other vendors to adopt

c. Most infrastructure assets on the internet run Linux-based operating systems, so even though they are purpose-built, often hardened appliances, they are still instances of high-privilege servers, and should be thought of, and protected, in similar ways; the same way you would never want to operate a high-privilege server without robust detection/response and observability capabilities, you should not permit an asset that your customer owns to run without those same capabilities. This thinking is what led us to embed EDR and employ it in our firewalls

d. This capability not only enabled us to accurately determine the state of exposure within our customer environment, but also helped us to stay one step ahead of our adversaries through their campaigns, more effectively keeping our customers out of harm’s way

e. This capability effectively becomes an enabler for “MDR for firewalls” or other on-prem, high-privilege assets, which is something that vendors could either choose to use as differentiator, or to monetize; today, Sophos considers this a differentiator

6. Seek, accept, and offer help

a. It is often tempting for cybersecurity vendors to behave guardedly when experiencing incidents such as Pacific Rim, for a variety of legitimate concerns, e.g. shaming/ridicule, opportunistic ambulance-chasing from competitors, or erosion of customer/partner confidence. But an incident is no time for pride, shame, or competition; it’s a time for collaboration and sharing in the interest of the customers that we’ve been charged to protect

b. Through the course of Pacific Rim, we collaborated with many organizations and agencies, including ANSSI, Bugcrowd, CERT-In, CISA, Cisco Talos, CTA, Digital Shadows (now part of Reliaquest), FBI, Fortinet, Greynoise, JCDC, Mandiant, Microsoft, NCA, NHCTU, NCSC-NL, NCSC-UK, NSA, Palo Alto Networks, Recorded Future, Secureworks and Volexity.

c. This approach was a significant component of our ability keep our customers, and the customers of other vendors globally, more secure

7. Focus on ought-to’s over obligated-to’s

a. Sometimes as a vendor you will find yourself confronted with difficult choices about how to best proceed through such adversary engagements. For example, you will have to make choices about the collection of indicators from customer assets across multiple countries with differing privacy laws, about whether to provide updates for versions of your product that are long out of support but which still have a significant footprint because of infrastructure inertia, about whether to incur costs associated with reaching out to customers who are non-responsive, etc.

b. A deontological approach, which focuses on our mission to protect as cybersecurity vendors, can offer clarity in such difficult situations

c. For example, even if you are not contractually obligated to provide an update for end-of-life products, and even if your code branches and test environments for those retired versions are in cold storage, don’t let the combination of a lack of obligation and the inconvenience/cost prevent you from making a reasonable effort

d. Foster healthy partnerships with your legal teams. There may be opportunities to safely push boundaries when taking actions to protect, and don’t use legal structures as a substitute for mature risk management practices, e.g. threatening to silence or lock out researchers

8. Control your own disclosure narratives and timelines, and enable others to control theirs

a. It’s helpful to begin with the assumption that whatever you know about the engagement and your response is going to become public at some point; use this to help inform the thoroughness of your disclosures and communications, and to find a balance between timeliness and seeking certainty

b. If you are a cybersecurity vendor who has discovered a vulnerability in a competitor’s product or operation, follow the same responsible disclosure practices that you would expect; prioritize protecting customers from harm over scoring magic cyber-points

9. Compete in the market, not in the heat of the moment

a. When a competitor is experiencing a newsworthy incident, whether an instance of an unforgiveable vulnerability in their product or a global outage, practice empathy. When customers, Support, Engineering, and Response teams are out of the woods, then it’s appropriate for us to vigorously hold each other to account to help drive an elevation of the entire industry

Cybersecurity vendors should ensure that we are all embracing the CISA initiatives, and the same way that we customarily engage in sharing threat intelligence, we should engage in sharing organizational and operational best-practices, including those that emerge from our hardships, like these.

Finally, some concepts to stimulate conversation within cybersecurity ecosystem about ways to improve the infrastructure inertia and Digital Detritus problems. By ecosystem, I refer to the collection of vendors, customers, regulators, standards bodies, researchers, insurers, investors, service providers, etc. who all play a role in cybersecurity. (And by conversation, I mean that these concepts are not meant as endorsements, but are offered as ideas to start a conversation — offered, at least in part, in the spirit of Cunningham’s Law.)

1. Certified lifecycles – As described, buyers and sellers have misaligned generational incentives. Although sellers have an incentive to shorten generational cycles, they would currently find themselves at a competitive disadvantage if they imposed time-based functional restrictions on their products while their competitors did not. For example, if vendor A chose to disable operation on their router or firewall after a certain end-of-life date, vendor B could advertise that they don’t impose such a restriction. This would give vendor B an advantage over vendor A, even though vendor A is taking active steps to reduce the Digital Detritus problem. One possible way to deal with this would be a “certified lifecycle,” in which products could achieve a recognized certification for adhering to a product lifecycle. The lifecycle could consist of the combination of: 1) a clear product deactivation date, 2) progressive notifications so that customers aren’t surprised, 3) a vendor-provided migration facility to simplify moving from one generation to the next, and 4) a recognition of the cybersecurity benefits from the cyberinsurance industry in the form of preferential products and rates.

2. Recycling – Electronic waste (e-waste) is already recognized as one of the fastest growing categories of solid waste in the world, with over 62 million metric tons produced in 2022. In addition to considerable environmental concerns, some elements of which regulatory conformity addresses, there is also a related cybersecurity problem: leaked sensitive data. The adoption of a certified lifecycle could exacerbate the problem without some offset. One possible way to deal with this would be greater incentives for recycling of infrastructure equipment. These could include both vendor preparation for recycling to ensure sensitive data is automatically securely wiped, including automated triggering as part of a certified lifecycle as a more secure default behavior; and government incentives that are more commensurate with the size of the problem, including awarding vendors and original design manufacturers (ODMs) for more modular designs that aid in upgrades and disassembly, more compelling awards for competitions such as the DoE’s E-SCRAP program to drive innovation in this area, and subsidies (e.g. tax credits) for vendors who invest in circular principles.

3. Secure by Design pricing markets – Alongside pollution, one of the most threatening negative externalities we face globally is greenhouse gas emissions. Carbon pricing takes a market-based approach to dealing with the problem through such mechanisms as carbon taxes and emissions trading, where good actors receive credits which they can then sell on the carbon market in the form of offsets to bad actors. These markets produce additional incentives for good behaviors, and they are not insignificant. For example, the Electric Vehicle (EV) company Tesla has earned over $9B since 2009 selling carbon credits to other automotive companies who were unable to meet their regulatory caps. A similar cap and trade market could be created for good Secure by Design actors (as measured by self-attested and randomly verified progress toward the pledge) to get credits which they could sell as offsets to others while they’re getting their acts together. Transparency in the market can also help to provide more information to buyers about which vendors are producers of credits, which are consumers, and the progress that they are making over time.

Conclusion

Among the ideas that Jen Easterly shared in her 2024 keynotes, she described a vision of “a world where cybersecurity is obsolete.” This on its face would seem to violate the need for the agency she directs, as well as the work that so many of us have devoted our lives to. While she admitted she was half-joking, it’s really not very different from doctors wishing that patients didn’t need their care; in other words, that their patients were pictures of health, and that they were professional golfers. I’ve always felt that cybersecurity could benefit from a broad adoption of a code of ethics the way that medicine has, our own expression of Hippocrates’ primum non nocere (first do no harm). The Secure by Design pledge scratches that ethical itch.

Medicine seeks cures but settles for treatments — not for job security as cynics sometimes claim, but because treatments are easier to come by than cures. The cybersecurity industry mainly deals in treatments, and CISA is attempting cures. Aspirins and vitamins, the metaphor goes; we will always need both to produce better outcomes for those we serve.

Sophos X-Ops is happy to collaborate with others and share additional detailed IOCs on a case-by-case basis. Contact us via pacific_rim[@]sophos.com.

For the full story, please see our landing page: Sophos Pacific Rim: Sophos defensive and counter-offensive operation with nation-state adversaries in China.