Survey of Supply Chain Attacks

Home Blog

The Atlantic Council has a released a report that looks at the history of computer supply chain attacks.

Key trends from their summary:

Deep Impact from State Actors: There were at least 27 different state attacks against the software supply chain including from Russia, China, North Korea, and Iran as well as India, Egypt, the United States, and Vietnam.States have targeted software supply chains with great effect as the majority of cases surveyed here did, or could have, resulted in remote code execution. Examples: CCleaner, NotPetya, Kingslayer, SimDisk, and ShadowPad.
Abusing Trust in Code Signing: These attacks undermine public key cryptography and certificates used to ensure the integrity of code. Overcoming these protections is a critical step to enabling everything from simple alterations of open-source code to complex nation-state espionage campaigns. Examples: ShadowHammer, Naid/McRAT, and BlackEnergy 3.
Hijacking Software Updates: 27% of these attacks targeted software updates to insert malicious code against sometimes millions of targets. These attacks are generally carried out by extremely capable actors and poison updates from legitimate vendors. Examples: Flame, CCleaner 1 & 2, NotPetya, and Adobe pwdum7v71.
Poisoning Open-Source Code: These incidents saw attackers either modify open-source code by gaining account access or post their own packages with names similar to common examples. Attacks targeted some of the most widely used open source tools on the internet. Examples: Cdorked/Darkleech, RubyGems Backdoor, Colourama, and JavaScript 2018 Backdoor.
Targeting App Stores: 22% of these attacks targeted app stores like the Google Play Store, Apple’s App Store, and other third-party app hubs to spread malware to mobile devices. Some attacks even targeted developer tools meaning every app later built using that tool was potentially compromised. Examples: ExpensiveWall, BankBot, Gooligan, Sandworm’s Android attack, and XcodeGhost.

Recommendations included in the report. The entirely open and freely available dataset is here.

Tags: reports, supply chain

Posted on July 28, 2020 at 6:40 AM • 33 Comments

Comments

Jean-Marc • July 28, 2020 8:36 AM

Wouldn’t it be worth mentioning that this think tank didn’t list the US or its allies in the report?

John Smith • July 28, 2020 9:31 AM

@Jean-Marc

Good call.

This bias is probably because The Atlantic Council is focused on US interests and achieving US objectives, and the study aimed at looking at challenges to those objectives.

Almost certainly there’s been studies on which supply chain attacks are the best ROI for computer intrusion and intelligence collection. We know the NSA has the Tailored Access Program, which has very sophisticated ways to attacking hardware distribution. One of the attacks by Equation Group affected the installation of software in target countries (they would send malware on CDs, for example). Of course, these are just two examples.

While attacks from Iran, North Korea, Pakistan, India, etc certainly affect me, I’m personally most apprehensive of the capabilities of the USA, UK and Israel due to their combination of partnership with my host country and their ruthless approach to both targeted and dragnet attack.

John Smith • July 28, 2020 9:35 AM

The results of the report are not themselves surprising, but the fact that there are enough examples know to start drawing out themes, commonalities and statistics surprises me.

Here’s the big question. The industry already has answers to supply chain security – such as code signing. Is there any easy better answer?

Another pertinent question. How many of these victims were “certified” by regulations and standards? What are those regulations and standards doing to strengthen their requirements to deal with these known cases?

echo • July 28, 2020 9:58 AM

The fact the Atlantic Council supported TTIP is a big red flag for me. No mention of course of Boeing versus Airbus and NSA shenanigans in Greece and Germany. As with a lot of things it’s not what is being said but what is being concealed which bothers me not to mention a few elephants in the room.

Clive Robinson • July 28, 2020 10:28 AM

@ John Smith,

The industry already has answers to supply chain security – such as code signing. Is there any easy better answer?

Sorry “code signing” does not protect the “supply chain” it’s a bit of a myth that’s been put around for years that is based on way to many incorrect assumptions.

You would have thought that the Stuxnet, flame, and duqu family of malware would have put an end to the myth but apparently not.

The big problem with “code signing” is that it only works in the upper layers of the computing stack and not below the ISA level.

Thus if I put in a hardware implant that recognises code, which is not exactly a hard task[1] with “standard libraries” and easily recognizable “system calls”, then it matters not a jot if the code is signed or not, because I change it in memory from below the CPU level in the stack.

Because the protection of “code signing” currently only goes as far as the OS linker or loader process and in most cases can not be used to check the code in memory due to other “security measures” such as address randomization etc (which is further proof that code signing is a bit of a busted flush).

[1] See the PDF Turing Award Lecture “Reflections on Trusting Trust” given by Ken Thompson,

https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

John Smith • July 28, 2020 10:58 AM

@Clive Robinson

Let’s be careful about language. Your response may be arguing a straw man, and I don’t want to waste your time.

Code Signing is one (just one) supply chain security control. There’s lots of security controls that apply to supply chain. It’s not a silver bullet. It’s not the only control.

The second set of attacks listed above in the link from Schneier discusses “Abusing Trust in Code Signing” as a supply chain attack. That’s why I mentioned it in my comment to begin with.

As you discuss, code signing does actually can apply up the chain from the ISA. Microcode updates to CPUs can be code signed for instance.

Anyhow, thank you for the comments.

Anders • July 28, 2020 11:23 AM

@John Smith

Let’s go back to Stuxnet. Why for example F-Secure didn’t
discover it and later Mikko Hyppönen publicly said that this
is embarassing[1]?

Reason is that they did rely on code signing and all the
samples that had valid signature were just considered “clean”
and passed them through without any further checking to ease
the workload.

That’s it, blind trust.

So please don’t come to talk about code signing as a god sent savior.

[1]
“We missed Stuxnet. We missed Flame. We missed them all. We missed them all for a year; some of them we missed for two years, which is really embarrassing.”

http://www.americanrhetoric.com/speeches/mikkohypponenwired2012.htm

echo • July 28, 2020 12:07 PM

Code signing is what it is. I have no idea why everyone is hyperventilating.

Clive Robinson • July 28, 2020 12:49 PM

@ John Smith,

Microcode updates to CPUs can be code signed for instance.

Only for some CPU’s and as far as I’m aware nobody has tested how well it does or does not work outside of simple fault injection attacks inspired by Tavis Ormandy. Or if the myriad of other CPU hardware faults comming to light since “Meltdown/Spectre” became the “Christmas gifts that just keep giving” can be used to circumvent it.

What we do know is that the hardware is full of attack vectors due to “specmanship” and accumulated crud/cruft. A point Prof. Herbert Bos of Vrije Universiteit Amsterdam, more than agrees with. As he notes,

“There are tons of vulnerabilities still left, we are sure,”

Which no doubt his team which has found many of the vulnerabilities so far are going to happily keep pursuing.

Of course Intel has not helped it’s self, it’s failed to fix vulnerabilities, but has implied it has and there are question marks over some of it’s seniors behaviour. It’s also repeatedly abused the standard vulnarability disclosure procedure, which is why researchers have not played ball with them in more recent times.

Also there is the question of what can be done with the “overlord CPU” at what some call “ring -3”. The Intel Managmebt Engine (ME( that apparently runs a version of Minix 3, and has as many vunerabilities found as for the main CPU including the development of a Rootkit for it…

Whilst Intel claim it is not a “backdoor” the fact that only the IC and Military in the US can disable it kind of suggests otherwise as does a line item in the NSA budget.

There is so much going wrong with Intel hardware that they have taken the “nuke and reorganise” route, which they announced yesterday. Apparently they have dumped their Chief Engineering Officer without stating why (though it might be due to a boardroom battle for the top job),

https://www.itpro.co.uk/hardware/laptops/356588/intel-oust-hardware-chief-following-7nm-troubles

Clive Robinson • July 28, 2020 1:03 PM

@ echo,

Code signing is what it is. I have no idea why everyone is hyperventilating.

Hardly “hyperventilating”, that said “code signing” is without doubt “a busted flush” what it achieves is very little and is very easy to subvert.

The real problem with it however is as a “sticking plaster on a broken bone” it should have been replaced with something way more effective three decades ago.

The simple fact is most of the IT industry use it as a “fig leaf” and rather than actually come up with a better solution they “Do a Nelson” and turn a blind eye and actively promote it’s myth.

It is at the end of the day an encryption system that has been repeatedly broken… Would you use a system that had been regularly broken to protect your privacy? I suspect probably not.

It’s just one of many signs of a failing industry. Essentially “half assed systems” are put in place as almost temporary work arounds and a quater of a century later they are still in place and nobody has been bothered to actually solve the underlying security issue.

John Smith • July 28, 2020 2:10 PM

Somehow people commenting here have misconstrued code signing.

I said: “The industry already has answers to supply chain security – such as code signing. Is there any easy better answer?”

What I was attempting to articulate was the need for the industry to improve. An easy and better answer to supply chain security than code security.

The responses to this comment have taken it to task based on a straw man, that somehow the original comment articulated code security is the answer. For instance @Anders has said “So please don’t come to talk about code signing as a god sent savior.”

I’m not sure where @Anders interpreted that I said anything about code signing being a god sent savior.

I agree with @echo. People hyperventilating here about code signing. Maybe because compliance/regulation/certification use it like its a silver bullet and the good folks here need a place to vent?

John Smith • July 28, 2020 2:12 PM

Before anyone takes me to task on the last comment I made a typo and wrote “code security” instead of “code signing” multiple times. Please s/code security/code signing.

echo • July 28, 2020 2:28 PM

@Clibe

Well, yes but this argument applies equally well to the local council. You can collapse anything if you attack every other entry point. The rest about fig leaves and bags of bolts is as true but code signing does a job. Not perfect but it stops a lot of crud.

If anyone is mega worried about hardware level exploit insertion or suchlike to subvert it that’s another problem.

I don’t expect Iran is too bothered about Stuxnet in retrospect. They got a nuclear deal.

Weather • July 28, 2020 3:08 PM

@echo clibe
Yeah I agree with echo, it stops a lot of stuff, eg you can’t replace certain Win binary unless at boot, which helps with the startup at boot issue. Run Exprocessmemory to change code create new rwx segment extra it doesn’t stop, but if you slowly chip away, if the opposition miss steps you can get cascading wins.
You have to pay for the ten cents 😉

Anders • July 28, 2020 5:48 PM

@John Smith

“I’m not sure where @Anders interpreted that I said anything about code signing being a god sent savior.”

Sorry, but read again your original expression.
It’s clearly a rhetorical question (“Is there any easy better answer?”). I wasn’t the only one who interpreted it in that way.
If you really want an answer, express it in that way (=please bring
me a better example or solution if there exist such etc).

Later you make lot of corrections to your postings (“Please s/code security/code signing.”). Think it through what you really want to
post. This is not a competition. There’s preview button. Use it.

John Smith • July 28, 2020 8:51 PM

@Anders

You misinterpreted what I wrote.

I can see how “Is there any easy better answer?” could be interpreted as rhetorical. Though, “Please bring me a better example or solution if there exists such” reads to me as WAY MORE rhetorical/challenging.

Your last post also reads to me as self-important and patronizing, though who knows if you mean it that way.

Anyway, this is my last post. Not getting a high enough SNR.

Thank you for your thoughts.

DisturbedShrimp • July 28, 2020 9:05 PM

Why was Israel not mentioned? or am I being antisemitic? Something about all Intel chips being shipped there for flashing and IME. Can anyone confirm???

Weather • July 29, 2020 1:09 AM

Microsoft wasn’t to hard, after the handshake, you just directed a Get request, to your server, you had to work out a basic hash, pretty easy to fined.

Phaete • July 29, 2020 1:17 AM

A sidenote should be the mentioning of companies like Samsung, Lenovo, Flight Sim Labs and more that don’t need an actor to put spyware in their supply chain.
They were so arrogant they put spyware in their software themselves.

End effect is the same, trusted software/hardware suddenly comes with spyware and takes most users unawares.

echo • July 29, 2020 1:32 AM

What gets forgotten is people can view security from different starting points. The salient question is perfect security is “perfect” for whom?

In the same way a nation or empire is not bombs and bullets neither is security simply about hardware and software. It’s about organisations and people, culture, and things like this. You get this discussion in a number of fields and not everyone understands it. In that respect it’s probably a good idea “perfect” security doesn’t exist because with perfect security comes perfect tyranny. And anyone I have met or heard of who claims a system is perfect is a person to avoid if you value your health and sanity.

Interdependency and human rights and open communications is also part of the security framework. Yes supply chain security matters but this isn’t just OMG “national security” but a simple policing and trading standards issue. I wouldn’t look to the US for guidance on any of this, tbh.

Clive Robinson • July 29, 2020 4:08 AM

@ echo,

What gets forgotten is people can view security from different starting points.

But everything has “foundations”, and if those are at fault then the whole edifice no matter what it’s usage comes tumbling down.

As you note,

It’s about organisations and people, culture, and things like this.

But unfortunatly these days in the West and other First World Nations society is built on technology all of which is built on computers from the humble 4bit microcontroler all the way through to the multi ARM core chips in high end super computers that have FPGA co-processors.

With regards,

In that respect it’s probably a good idea “perfect” security doesn’t exist because with perfect security comes perfect tyranny.

Neither can be “perfect” for various reasons to do with mathmatics and the laws of physics as we currently understand them.

Perhaps oddly the proof that computers as we currently use them –Turing Engines– could not be secure arived before computers did.

From my point of view way to few people realise just what rests on top of computers these days and what would happen if they became unavailable or untrustworthy. In the former case people talk of EMP and CME events wiping them out, and then hypothesising from there with that delightfull,

“We would be back in the steam ages but without the steam engines.”

Neglecting to mention that it would actually be worse a lot worse than that due to our over reliance on “force multipliers” and “control systems” just to “shift the shit” out of our cities and suburban areas. Likewise the loss of water and then food supplies. That is the world population back just before the steam ages was a fraction of the size it is and it was getting wiped out by disease and malnutrition as it was… Transport was by foot power or by horse or wind all were slow unreliable and inefficient.

But easy as that is to find out by historical research, it does not address the issue of computers becoming universaly “untrustworthy”… A few SciFi writers have talked about some of the potential distopian results. But we are actually seeing it for real. Some have realised why using computers in elections is an incredibly bad idea, but we are still being pushed that way. Some have suffered Doxing, others Identity Theft and all the attendent mental anguish rage and frustration that goes with being a victim of either crime. Unfortunately we tend not to take seriously the ways that the new “personal assistants” like Siri, Alexa et all can be spoofed or tricked.

But how few think about “smart meters” and the insistence by some politicians that you heating, air conditioning, fridge-freezer etc come under “smart grid control” realy just to save those giving kick-backs in the power supply industry doing adequate maintanence and future capacity building so that next quaters profits look better than they should do…

Unfortunately in less than a century we have become totaly and I realy do mean totaly dependent on computers big and small. You have to be “a child of the sixties” to remember times when we were not, oddly times when steam trains still ran in the UK.

The problem is that with time attacks on computers are going down the computing stack, and increasingly beyond the point where “software defences” will defend us. Thus unless we change how we are doing things our systems will become less and less trustworthy. As you and most readers here are aware there is no financial incentive to cause us to change… Thus when do we reach a tipping point where it is “to late to change”?

Who? • July 29, 2020 4:16 AM

@ John Smith, Clive Robinson, and Anders

Years before our open source project started signing its code, another developer asked how reliably detecting a malicious copy of our operating system being distributed from a mirror. My answer was simple⸺just download a strong checksum, i.e. one with no known collisions, from the main repository, or even better two different checksums for the same ISO image and test it. He complained that a checksum is not something we should trust to authenticate code. In some way he was right but if checksums on the main repository have been tampered, how will signing improve this situation?

Let me put it the other side. TAILS, an unrelated software project targeted to privacy, has provided signed code for years, but they distribute both certificates and signatures from the same repository the ISO images are available. Anyone looking to distribute a tampered TAILS release only needs to set up its “TAILS web server” with the modified images signed by a certificate that looks authentic, providing both the digital certificate and ISO images signatures from the same repository, just like TAILS does. This attack cannot even be considered a supply chain one.

echo • July 29, 2020 6:21 AM

@Clive

I had a long and probably over-clever reply drafted then experienced an ironic brown-out. My laptop is docked and lazily I had left the battery in but one thing led to another. “C’est la vie”. This was pretty much my answer before. I’m not being blasé about the issues you exhaustively mention but the Atlantic Council and their shady backers aren’t the only pebbles on the beach.

I think solutions and education and pushback can help a lot. You can see traces of this in the Russia Report and pandemic response and various other tilts like Macrons statements on ITER, the news on the new Airbus A350 pilotless takeoff and landing system, and renewable energy achieving zero subsidy. It’s helping rebase the emotional response to technical issues and the politics and society behind this. With this comes change and it can be quite rapid once it begins.

The seatfiller in Parliament are almost always reactive. Without getting into the constitutional stuff there isn’t much they can do if people build solutions. Even the most power crazed state sector jobsworth and quasi-judicial body is a gutless wonder when you get down to it.

Few people get into technology for the technology, or science for the science, but the romance and poetry. This is partly why engineering gets trumped by marketing. It’s also partly why Bruce has a bigger popular audience than the kinds of people who read the proceedings of IEEE or why an otherwise unremarkable toad faced Neo-Nazi was able to bankrupt the UK. I don’t think the fact we no longer have shows like Tomorrow’s World or Euro Direct is helpful because it elbows experts and other ways of feeling about things out of the way and people do need this. The fact MI5 fell down on their own statutory obligations didn’t help either. In that respect it’s remarkable during this pandemic which was a trial run for a lot of silliness that people got their technical and cultural news off twitter and youtube in spite of massive institutional and government failures and the failures of the platforms themselves.

Ismar • July 29, 2020 7:31 AM

I see code signing in the same light as the certificates used for establishing the chain of trust ( best known example is with browsers to establish secure connection and attest the authenticity of the remote website/ machine).
They are put in place by an authority to try and monopolise the control over a system. In other words , we are the only ones who can get unfettered access here while preventing other jurisdictions from doing so.
This can be a good thing in public systems such as power supply grid (for example) where the operator the system is made more robust by knowing the origin of the code but only if all of the levels of the system (from firmware to the application) are controlled by the same jurisdiction where the system is used.

The mindset of getting things done on the cheap has finally reached its limits as we are slowly realising that getting things done on a cheap side to build our most important infrastructure can backfire in a major way.
This should, hopefully, lead to more investment into local capabilities and expertise and becoming more self reliant making sure all of the supply chain is under the control of the same jurisdiction.
Now, can somebody offer me a position on an lobbying body for local high tech industries so that we can get this going ????

Weather • July 29, 2020 11:35 AM

@clibe
Emp and CME should effect us around 2031-32 , a three star system 400 light years away has gone supernova, it was expected to happen one million years from now, but based on modified physics laws, we should be getting a hit by then.
Good news I’ve been wrong before 🙂

myliit • July 29, 2020 11:49 AM

Is there some sort of canary or way to know if and/or when to stop accepting signed Apple security updates?

In the USA and elsewhere.

Anders • July 29, 2020 5:11 PM

RE: code signing.

“In this report, we show that this flexibility allows attackers to completely change a document’s content while keeping the original signature validation status untouched.”

pdf-insecurity.org/download/report-pdf-signatures-2020-03-02.pdf

Who? • July 29, 2020 5:51 PM

@ Anders

PDF security model is a joke⸺in front of me there is a library that has quite a few binded non-printable PDF documents.

SpaceLifeForm • July 29, 2020 6:21 PM

If you use Grub2 and Secure Boot, you may have a looming supply chain problem.

You are dependent upon Microsoft.

hXXps://capsule8.com/blog/grubbing-secure-boot-the-wrong-way-cve-2020-10713/

This vulnerability resides in step #3. GRUB uses a language parser (generated via flex and bison) to read the config file. If the text in the config file is too large, the flex engine says “no thank you!” with the expectation that the processing function will exit or be halted. Quite unfortunately, GRUB’s implementation does not fulfill that expectation. Instead, GRUB is like, “Oh, a fatal error indicating that the string is too big for the buffer? Cool, cool, cool, I’ll copy it straight into the buffer so we can proceed with executing the function!”

hXXps://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

Mitigation will require new bootloaders to be signed and deployed, and vulnerable bootloaders should be revoked to prevent adversaries from using older, vulnerable versions in an attack. This will likely be a long process and take considerable time for organizations to complete patching.

Clive Robinson • July 30, 2020 6:56 AM

@ SpaceLifeForm,

GRUB is like, “Oh, a fatal error indicating that the string is too big for the buffer? Cool, cool, cool, I’ll copy it straight into the buffer so we can proceed with executing the function!”

Yet another “lets fill the buffer till it blows” attack…

You’ld have thought that people would be wise to that old chestnut by now, and send not just the excess but what got into the buffer as well to the great bit bucket in Hades…

And before anybody says buttt… Yes I’m aware that a bust config file that gets dumped and the system reboots is a recipe for “endless wonder” on the “big hamster wheel of pain” but there are other ways of dealing with it.

The most sensible if you want to get the system into a “sane” state is to have a very minimal “recovery” config it drops into with a diagnostic message and the option to “edit, repair or replace” the file.

The problem is that will not get you into a “secure” state because of passing flags to the OS kernel, which mostly takes the “sane” state over the “secure” state, thus you can end up with a root shell in single user mode etc.

But the simple fact is that you can boot PC hardware via a USB drive etc if you wish to, or just take the hard drive out and get at it that way. Then there is the Intel Managment Engine can do as it darn well pleases so “secure” is not exactly much more than “a fig leaf” anyway.

Thus the best the “secure” way can go is to force a complete reinstall and kiss good bye to any and all user data etc if the user has not partitioned things up correctly.

But lets consider why this mess started in the first place…

Yup it was the ICT industry “responding” to the Entertainment industry that decided that their whants and whims should prevail over everyone elses[1]… The excuse used back then was it would make the “user experience” more secure… Which is the same debunked nonsense argument you get with all “Walled Gardens” used to exert often illegal monopolistic control over others, which like most Empires almost always fall.

So what should Grub realy do any way?

It’s primary fault is it’s way to trusting of input and the reliability of the originating hardware etc. That realy needs to be fixed at the lowest levels.

Thus the first step is it “should get into and remain in a sufficiently sane state” right at the begining by being defensive not trusting. That is it should go “sanity check” not just the boot partition but the required files within before trying to use them. So if a fault is found it should then “halt on fail” and put up a sensible error message and still be “sane”. Anything less than this is pointless.

After that it’s behaviour should be “sane” for one version of Grub and “secure” for another version of Grub depending on which one the user originally chose.

The real problem for “secure” though, is still the “root of trust”. If you actually owned the system you would be able to have your own private root of trust to which everything else is subservient. However that has issues such as,

“Has a secret master root of trust been installed by the hardware manufacturer, or in the supply chain.”

In effect Intel’s Managment Engine is a path around any “root of trust” anyway due to the way computers currently work (or don’t when it comes to security).

However what I would do however is make config files quite a bit more robust, just a “text file” is realy not good enough, especially when you consider the tricks used on “journaling” and more advanced file systems…

Back nearly five decades ago when CP/M was the aspirational OS of Intel 8bit computing and modems were 300baud and more expensive than a car… Due to unreliability in getting a “file” from one place to another Motorola amongst others came up with a “checksumed” file format where lines in “the file” were of limited length and each one was checksumed. The assumption was you could contact the originator of the file knowing which line was at fault and manually correct it with a simple line editor like “edlin” etc.

These days we have better checksums which can automatically say where an error is if not correct it. Thus with both Error Correcting Codes (ECC) and what is called Forward Error Correction (FEC) where the data is atleast triplicated in a dispersed way errors in files can be reduced to a point of near insignificance. Which whilst it helps “sane” does not help “security” because of the root of trust issue.

[1] From what I can tell all those “wants and whims” have done the “old guard” Entertainment industry little or no good. As with all unfair monopolies people have gone in different directions and that’s included most new entrants in the Entertainment industry, going with “online” models (which can be made secure if desired). But the new comers have found it’s realy not necessary and all those “wants and whims” of the “old guard” Entertainment industry are –for now– gone, thus the old guard has had to fall in line with the new or go the way of the Dodo.

littoral • July 30, 2020 12:04 PM

The entire report is a smokescreen. The sum total of all the attacks described is surely negligible compared with NSA attacks.

A main purpose of the Atlantic Council is (according to its own website) is to “support constructive US leadership in the world”.

Do China and Russia engage in attacks on the integrity of software we use? The report is probably correct to conclude that they do. But I am pretty sure that their efforts are negligible compared with what the NSA does. I’m disappointed that Bruce gave credibility to this attempt to distract attention from the worst source of malware on earth.

anon • July 30, 2020 12:17 PM

Most of the links in this post are broken because they have “%22%20%5Ct%20%22_blank” at the end of the href.

WhiskerInMenlo • August 17, 2020 5:36 AM

Unfolding … hobbling transport, ordering and payment by restructuring the USPS without a working option seems to apply.
Shortly on the heals of the election is the largest shopping spree the year is likely to see.

To Sustain and restart the economy correspondence, goods, payments need to be unencumbered and predictable.

There is a rather large and key link that just was removed or weakened..

Survey of Supply Chain Attacks

Comments

Leave a comment Cancel reply