Tuesday, July 7, 2020

This is (probably not) my last post on product risks!



In this post last Tuesday, I reported on a call I’d received from a friend who works as an engineer at an important supplier of hardware products to the electric power industry. He’d called me after my Monday post made the point that I don’t believe there are true product risks, just vendor risks that apply to products.

My friend brought up a case that his company encountered. To quote my post:

There was a particular piece of third-party software that the supplier (i.e. my friend’s company) provided to their customers to use for collaboration with the supplier (so it wasn’t incorporated into one of their products). There was a vulnerability in this software that might have allowed an insider to gain control and do bad things. Despite this vulnerability, the supplier felt this product was still worth using, and they made a point of telling their customers about the vulnerability and how to mitigate it. Was this a product risk?...

I pointed out the difference between a vulnerability and a risk (in my way of thinking, of course). Software and firmware vulnerabilities occur all the time, but in my opinion they don’t constitute an actual risk unless the supplier a) doesn’t develop a patch in a timely manner, and b) doesn’t inform their customers and work with them to mitigate those vulnerabilities until a patch is developed, which is of course the best mitigation for a vulnerability…

…the risk is that a supplier will distribute third-party software that has an unpatched vulnerability that they know about but can’t patch (in this case, it’s because this software wasn’t part of one of their products – so they have no access to the code to develop a patch. And the third-party supplier wasn’t providing their own patch, for some reason), yet they also don’t inform their customers of the vulnerability, or how to mitigate it. Had this supplier not informed their customers of this vulnerability, it would have posed a serious risk for their customers. But of course this supplier did tell their customers and did suggest mitigating steps they could take… this supplier mitigated the risk as they should have done.

The next day, I got an email from Kevin Perry, bringing up an example he thought was a product risk:

…you cite the supplier as a risk because it knew there was a vulnerability and chose to tell their customers.  The key part being the supplier knew about the vulnerability.  Whether it chooses to inform simply defines the risk.  But what if it is a zero-day vulnerability, either as a result of an unknown software vulnerability or a hardware issue?  No one knows the vulnerability exists until one day you get taken down.  Does that change anything?  I look at this with the side channel vulnerability that exists in almost all modern computer processors.  Yes, the feature was designed into the CPU for processor speed.  The unintended consequence is that a well crafted exploit can take advantage of the feature to cause an exception and access the contents of the memory look-ahead cache before the exception handler clears the cache.  It is possible to read memory outside of your process boundaries.  Is this a supplier risk because you bought your computer from Dell or HP and it came with an Intel or AMD processor?  Is it Intel’s or AMD’s “supplier” risk?  Or is it truly a product risk.

Yes, once identified, there have been work-arounds developed.  And as soon as a work-around is developed, a new exploit path is found.  In the end, only a complete redesign of the CPU and replacement of any computer containing the old processors will resolve the issue.  I am having problems characterizing this as a supplier risk.  In my mind, a mitigation of a supplier risk could be to change suppliers.  In this instance, there is no supplier that does not have the vulnerability in their processor’s module

In other words, Kevin is pointing to an unpatched (and unpatchable, in this case) vulnerability in a processor as an example of a true product vulnerability. My reply was:

It seems you're actually addressing three separate potential risks. The first is the risk that the supplier will know of an unpatched vulnerability but won't tell you about it. That's what I discussed in the post, and I think you agree with me that this supplier mitigated that risk by telling their users about the vulnerability. But not all suppliers can be counted on to do this! That's why CIP-013 R1.2.4 is there.

The second risk is that there will be a true zero-day hardware or software vulnerability in the product. Of course, the supplier can't tell you about this because they don't know about it either. But I don't call this a risk. Literally every digital hardware or software product in the world could have an unknown vulnerability in it. The only thing a supplier can do is be as vigilant as possible in looking for vulnerabilities (but even if they find a true zero-day vulnerability in their product, they will then know about it and it won't be zero-day any more. So risk no. 1 applies). And the user can be as vigilant as possible in testing the product, etc. 

The third potential risk is that a hardware or software supplier will have a vulnerability in their product, which they can't fix at all - absent a complete redesign, as in the case of the Intel/AMD side channel vulnerability. This seems to me to be just another example of risk 1. The supplier can't patch the vulnerability, but they can at least tell you about it and let you decide whether or not you want to continue using the product. Of course, AMD and Intel have been quite open about this vulnerability, so I'd say they've mitigated the risk, just like the supplier in yesterday's post mitigated the risk by telling their customers about it. The customers then have the choice of either accepting the residual risk or not using the product at all (I'm assuming here that there's no good software mitigation or workaround for this vulnerability). In the case of the supplier in my post, it would be fairly easy not to use the vulnerable software, since it isn't required for the operation of the product itself. In the case of Intel/AMD, it would be very hard to simply move away from that architecture, so my guess is almost all users have formally or informally accepted this risk

At that point, our discussion split into three separate threads, but at least two of them led to the same conclusion as the thread below. Kevin defended the idea that the processor vulnerability actually is a product risk by saying:

Any time I acquire hardware or software, there is a risk that (1) the purchase will not perform as expected or intended, (2) I will not get exactly what I thought I was (product substitution), or (3) there will be failure points or vulnerabilities that I need to address in order to protect my networking and computing environment.  Just because I do not know that a specific vulnerability exists at the time I purchase the product does not mean that risk is absent and that I need to do nothing.  Depending on what the product does and where it is placed in my network will drive the risks that I need to mitigate to the extent possible.

I replied:

This is an installation risk, which is an entity risk. You need to make sure you take into account the risks that apply to the environment in which the product is being installed and apply controls that are appropriate in that environment. The risk is mitigated by training, mentoring, etc. Of course, installation risks are specifically addressed in CIP 13 R1.1.

So I continue to believe: There are no product risks, just supplier risks and entity risks. In my first post, I just said there were supplier risks, but there’s actually another type of supply chain risk – risks posed by your own organization. I didn’t bring entity risks up earlier because I didn’t think they were relevant to this product risk discussion. But the next day (last Wednesday), another friend wrote in, and that led me to realize that entity risks might masquerade as product risks also. I discussed that in this post.

Do I think this is the end of the discussion? Not by a long shot.


Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Are you working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!



Monday, July 6, 2020

It’s been one year…



Note from Tom: A year ago today, I saw a post by Mike Assante in my inbox. The post I wrote after reading it has drawn more views than almost any other post I’ve written in about eight years, and I can see that people keep returning to it. Here is that post. I’m also including the post on Mike that I wrote a few days later. I feel just as sad now as I did then.


A farewell from Mike Assante

I just read on the SANS ICS Community perhaps the saddest post I've ever seen. It's by Mike Assante, former NERC CSO (in fact, I believe he was the first one), and someone who has been hugely important to the industrial cyber security field, and especially to grid security. To read about his accomplishments, you can go to his LinkedIn page.

He has been battling leukemia for a long time, and there have been ups and downs. This post is his farewell. When I first saw it, I thought he had written it because he had been told that the end was near. However, as you can see, he wrote it while he still could, with instructions that it not be posted until he had passed on. I hadn't heard that he had - and LinkedIn and the SANS website don't mention this at all yet - but I take this as notification of his passing.

Even though I didn't know him very well, I'm really going to miss him! As a final note, I'll point out that he concluded with a joke. Here's Mike's final post:

As you might have surmised this note is a goodbye to this ICS community.  I have been in a long, hard fight with Leukemia and it has come to an end.  I wanted to provide a final update to all my friends and the general ICS community upon my passing, as well as to provide my support in what all of you have chosen to do in your careers.

I have had the honor to work alongside so many talented and passionate professionals throughout the years.  I need you to know that what you do and how you do it matters to communities, to companies, and to our nations.  I have worked hard alongside some of the greatest people to demonstrate the risks, provide strategies to manage it, and now to develop the workforce to enhance its security. 

I am especially proud to have collaborated with the communities from inside of Idaho National Laboratories (INL) and SANS.  I leave behind the people I loved to work with, especially as they are so focused on making a difference.  I want to thank all of you for what you do and what you have done, and I want to say farewell!

Continue your hard work and be confident that it is noble to protect infrastructures and your organizations value.  Your work is more important than most organizations understand, but we continue in it out of a sense of duty and passion.  You must carry-on, keep sharing with each other, and use this forum to continue to help our community.  I now get to take a whole new look at another infrastructure, but this time it’s in the sky (and I’m not talking about the 737 Max)! 


Here's the post I wrote two days later, on July 8:

Mike Assante

I just can’t get Mike’s parting message to the ICS security community out of my mind. I can’t put aside the fact that, when he was obviously very near the end and probably very weak, as well as distracted with thoughts of the family he was leaving behind (including young children), his number 2 concern (after his family, I’m sure) was the unsung throngs of people working day by day to help make the grid more secure.

Notice he didn’t name any names, or ever say something like “…and I especially want to thank Joe Jones for his immeasurable contributions…” Instead, look at the first three sentences of his last paragraph, before the last sentence (which was a critical infrastructure joke, and quite timely): “Continue your hard work and be confident that it is noble to protect infrastructures and your organization’s value.  Your work is more important than most organizations understand, but we continue in it out of a sense of duty and passion.  You must carry on, keep sharing with each other, and use this forum to continue to help our community.”

Almost literally Mike’s last published thought was about the people who work for organizations that don’t bestow on those who labor in their security vineyards either the monetary or psychic rewards they deserve. His message: “Your work is important and noble. You must carry it on, but you’re not alone. There are many others doing the same thing. You can all support each other.”

Rest in peace, Mike.



Wednesday, July 1, 2020

There’s a third type of risk!



Note from Tom: If you’re only looking for today’s pandemic post, please go to my Pandemic Blog. If you’re looking for my cyber/NERC CIP post, you’ve come to the right place.

A longtime friend wrote to me today to point out something he thought might be a product risk, not a supplier/vendor risk, based on my Monday and Tuesday posts. I was able to convince him it wasn’t a product risk, but I also had to admit it wasn’t a supplier/vendor risk either. There’s a third type of risk that I was leaving out of this discussion, but which is very much relevant to it – as I now realize.

My friend’s idea was that there are some products that users are prone to misconfigure, which can leave a system subject to cyber attacks. As an example, he brought up the attack that was reported on an OE-417 form last March, which was the first reported successful cyberattack on the US Bulk Electric System. There were two problems that led to that attack:

The first problem is that the attackers exploited a vulnerability in Cisco’s IOS that had been patched by Cisco – however, the organization that was attacked hadn’t applied the patch yet. As I pointed out in Monday’s post, if a vulnerability appears in a product and the supplier doesn’t either issue a patch for it or – if for some reason they can’t patch it immediately – let their customers know about it and provide help in mitigating it, this is a supplier risk (in fact, it’s the risk addressed by CIP-013-1 R1.2.4). But Cisco did issue a patch, so it was mitigated by them – yet a patch never does you any good unless you apply it! So apply it (and you can quote me on that one).

The second problem was that the router’s web interface was connected to the public internet (no doubt to make somebody’s job a little easier…), which as we know should never be done. In fact, my friend believes the attack probably wouldn’t have been successful if this hadn’t been done.

Of course, this isn’t Cisco’s risk. This is just good security practice for control systems in general – they should never be directly connected to the internet. This isn’t a product risk, but of course it also isn’t a supplier risk. In Monday’s post I didn’t mention any other type of supply chain cybersecurity risk, but there is one: risks posed by the end user organization itself.

The biggest category of organization risks is insecure installation: The product has all the needed security capabilities, but the organization doesn’t make sure it is installed securely and it ends up being exploited. The mitigation for this risk is of course training for people doing installations, although one of my clients suggested “peer reviews” that their people do for each other, to confirm their work. I’m sure there are other mitigations as well. Of course, installation risks are covered by CIP-013 since they’re mentioned explicitly in R1.1.

So I continue to believe there are no true product risks, but I was wrong in saying that there is only one alternative: supplier/vendor risks. There are also risks due to the organization purchasing the product. These have to be mitigated just as much as supplier/vendor risks do – and of course they’re a lot easier to mitigate, since I have yet to identify one that required more than implementing a policy, procedure or training to mitigate. Of the 100 or so important supply chain cybersecurity risks that I and my clients have identified, around 15 or 20 of them are risks due to the NERC entity itself.


Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Are you working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!



Tuesday, June 30, 2020

More on “product” risks



Note from Tom: If you’re only looking for today’s pandemic post, please go to my Pandemic Blog. If you’re looking for my cyber/NERC CIP post, you’ve come to the right place.

Today I received a call from a friend I’ve known for a while, an engineer with a major supplier of electronic devices to the electric power industry. The call was about yesterday’s post, in which I explained why I didn’t think there was such a thing as a product risk – just supplier risks that can be realized in their products (although I didn’t use exactly those words).

He brought up to me two cases having to do with third-party software that this supplier either incorporates into its products or provides with them. In both cases the third-party products contained unpatched vulnerabilities; he was wondering if these might be examples of true product risks.

The first case was in a protocol stack that the supplier licenses from a third party. It seems there were a few unpatched vulnerabilities in the software. Because the supplier hadn’t implemented the parts of the stack that included those vulnerabilities, they felt they had no obligation to try to incorporate their own mitigations for those vulnerabilities; moreover, they weren’t obligated to inform their customers of them. Did this situation constitute a product risk?

The second case was of a particular piece of third-party software that the supplier provided to their customers to use for collaboration with the supplier (so it wasn’t incorporated into one of their products, as in the first case). There was a vulnerability in this software that might have allowed an insider to gain control and do bad things. Despite this vulnerability, the supplier felt this product was still worth using, and they made a point of telling their customers about the vulnerability and how to mitigate it. Was this a product risk?

As we discussed these two cases, I pointed out the difference between a vulnerability and a risk (in my way of thinking, of course). Software and firmware vulnerabilities occur all the time, but in my opinion they don’t constitute an actual risk unless the supplier a) doesn’t develop a patch in a timely manner, and b) doesn’t inform their customers and work with them to mitigate those vulnerabilities (until a patch is developed, which is of course the best mitigation for a vulnerability).  

In both of these cases, there is a risk, but it’s a supplier risk. In the first case, the risk is that a vulnerability in third party software – which is incorporated into a product that the supplier sells for use with BES Cyber Systems – won’t be patched by the supplier (although in most cases the third party would have to develop the patch, and the supplier would just need to apply it or distribute it, e.g. in a new version of a software library). But I pointed out that, since the supplier wasn’t using the portions of the third party code that contained the vulnerabilities, that code wasn’t part of their product at all – and therefore this risk doesn’t even apply in this case.

In the second case, the risk is that a supplier will distribute third-party software that has an unpatched vulnerability that they know about but can’t patch (in this case, it’s because this software wasn’t part of one of their products – so they have no access to the code to develop a patch. And the third-party supplier wasn’t providing their own patch, for some reason), yet they also don’t inform their customers of the vulnerability, or how to mitigate it. Had this supplier not informed their customers of this vulnerability, it would have posed a serious risk for their customers. But of course this supplier did tell their customers and did suggest mitigating steps they could take.

So was there a product risk in either case? In the first case there was no risk at all, since the vulnerabilities were in code that wasn’t incorporated in the supplier’s products. In the second case, there was a risk, but it was a supplier risk, not a product risk. And this supplier mitigated the risk as they should have done.

So I continue to believe there are no product risks, just supplier or vendor risks. But I could be wrong – I’d love to hear if you have any counterexamples.


Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Are you working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!



Monday, June 29, 2020

Is there such a thing as a product risk?



Note from Tom: If you’re only looking for today’s pandemic post, please go to my Pandemic Blog. If you’re looking for my cyber/NERC CIP post, you’ve come to the right place.

I’m currently working on a book on CIP-013 with Steven Briggs, a cybersecurity and compliance professional who works for a large electric utility and has been very involved with CIP-013 since the drafting phase. One of the issues that we’ve debated (and not necessarily resolved) – and which I’ve debated with others as well – is whether there are true product risks. Or are there only supplier risks, some of which apply to products?
At first, this seems like an easy question to answer: Of course there are product risks! Some products come with insecure configurations, such as a backdoor intentionally planted in the code to make the developers’ lives a little easier, which the supplier never removed before the product was shipped to you. Others come with unpatched software or firmware vulnerabilities, possibly because the product was sitting in a warehouse for a couple months before it was shipped and the latest patches weren’t applied before shipment. There are many other possibilities as well.
But what’s the best way to mitigate these risks? Both of the risks just mentioned are primarily due to poor practices on the part of the software supplier. The best mitigation for these risks is to get the supplier to implement proper procedures (such as applying the latest patches before shipping any product) so that incidents like these never happen. If the best way to mitigate a risk is to get the supplier to change their policies or procedures, it’s hard to imagine these are anything but supplier risks.
But here’s a risk that calls that conclusion into question: the risk that a hardware product will allow firmware upgrades and patches to be applied remotely without any authentication. This vulnerability was exploited by the Russians to “brick” RTUs in the first Ukraine attacks in 2015, so it’s definitely a real risk. However, it’s been five years since those attacks and many (most?) control systems purchased for field use (especially in substations) still don’t require authentication for firmware upgrades.
Is this because the suppliers of these devices are nefarious criminals who just care for the almighty buck, not for the security of their customers, let alone the Bulk Electric System? No. It’s hard to imagine that anyone is buying these products nowadays without being fully aware that this vulnerability is present in them, and we hope that suppliers aren’t hiding that fact. There are probably three reasons why nothing much has changed since the Russian attacks:
  1. There are lots of legacy devices in the field that have this vulnerability. Since replacing them would be very expensive, especially if it would require changing suppliers, there’s not much incentive to replace them before they fail or become obsolete for other reasons.
  2. As with anything that users would like to have, there’s a cost to it. A lot of control system suppliers might not be interested in being the first kid on the block to implement this, since it might make them non-competitive.
  3. Probably the most important reason for non-action is that Medium impact substations all have good external security now, due to having to comply with CIP-005-5 R1 (Electronic Security Perimeters); it’s hard to imagine how an external attacker would be able even to ping the device in the first place. Of course, this doesn’t apply to Low impact substations, although with CIP-003-8 in place now, you might also consider that a mitigation. 
So is this a supplier or a product risk? Let’s say the supplier now designs authentication (or digital signature verification) of firmware upgrades into all new devices. Since their customers know that the supplier’s legacy products still have this vulnerability, while at the same time all future products won’t have it, the supplier has done all they can. If the user can live without authentication, then they can keep buying the legacy products. If they have to have authentication, they can either buy new products or else change suppliers (and I don’t know whether any suppliers are offering authentication even now). It’s up to the utility to mitigate this risk from here on out, at least as far as procurements from this supplier are concerned.
Does that make this a product risk? No, it’s still a supplier risk, but it turns out that the primary mitigation – having the supplier bake authentication of updates into the firmware – can’t be applied in this case, so you need to mitigate this risk through your own measures. This is why there always needs to be at least one “backup” mitigation for each supplier/vendor risk – i.e. a mitigation that your organization takes on its own (the NERC FAQ on CIP-013-1 made this point very clearly). As mentioned above, if this is a Medium impact substation the risk is probably already mitigated, due to the fact that your organization is compliant with CIP-005-5 R1 (although this needs to be documented).
But there’s one other consideration here: People have stated to me that the fact that product X doesn’t offer a particular capability – say it doesn’t allow use of more than two types of special characters in passwords – constitutes a product risk. No, it isn’t a risk. It’s a feature, or more accurately a lack of one. For example, if you were designing a public kiosk, you wouldn’t consider it a risk if the product didn’t require passwords at all, let alone if it didn’t require complex ones. But if this were a sensitive military system, I’m sure it would have to have all sorts of capabilities that aren’t available at all in the commercial market.
Whenever any organization buys any product of any type (even pens), they should always inquire about the features they’re interested in having. And if the feature isn’t there, they shouldn’t buy it. Organizations have been doing this since…perhaps the founding of Rome.
So if you didn’t inquire about password complexity up front when it was a feature you absolutely needed, shame on you if you’re blindsided when you discover it’s not there. If you get a product that doesn’t allow complex passwords and you wanted to have them, you haven’t been a victim of a supply chain cyberattack – you’ve just been stupid (of course, stupidity itself is a risk, and if you believe there’s an abundance of stupidity in your organization, you need to consider this risk in your Procurement Risk Assessments – and take steps to mitigate it, like only allowing smart people to be involved in the procurement).
Now, there is a risk that a supplier, after having promised that an important feature will be included in a product you are going to purchase, doesn’t in fact include it. This is a supply chain cybersecurity risk. The best mitigation for it would be to have a term in the contract (if there will be a contract for this Procurement) stating that the feature will be included, and if it’s not included you have the right to return the product and maybe even charge the supplier a penalty.
In fact, I can’t think of any “product risk” that isn’t actually a question about whether a particular feature is present. And this is why I believe that all real risks having to do with products are actually supplier risks; but I’d certainly like to hear from you if you disagree with me.


Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Are you working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!



Saturday, June 27, 2020

A dispatch from the front lines of the Covid-19 crisis


Note from Tom: Jude Gamel, a recently retired critical care nurse who lives in Kentucky, started corresponding with me a few weeks ago about my pandemic blog. We hadn’t discussed his own experiences (and those of his former colleagues, whom he keeps in touch with regularly) treating Covid-19 patients previously. But yesterday, he was inspired by that morning’s post, which focused entirely on deaths from Covid-19, to describe, in two emails, what “successful” outcomes are – i.e. when the patient survives. In many cases, the patient might well wonder whether the physical, emotional and financial toll on them were actually better than dying. And there’s also a huge physical and emotional toll on the health care workers. His account is gripping.

Jude’s first email
I just finished reading you post for today. I would like to add or at least to comment on something that too often gets lost or goes missing in conversations about Covid-19 and I think it is particularly relevant to what we see happening now: there are some outcomes that are almost as bad as dying and Covid-19 is a perfect example. Let me see if I can articulate this properly in order to make this clear.

Take for instance ICU beds. Most patients admitted to an ICU are admitted because they require specialized care and monitoring that cannot be done on another unit or floor. It is usually just to get a patient through a critical point. A clear example of this is a patient recovering from Open Heart Surgery. They generally spend 24-48 hours in a Cardiovascular Intensive Care Unit and are then discharged to a Step-Down Unit and then home or to a re-hab facility for recovery (roughly 7-10 days). A patient who has a Myocardial Infarction (Heart Attack) goes to a Catheterization Lab and gets stented and spends, again, 24 hours or so in an ICU (if even that). Now more complicated situations like Sepsis, Diabetic Ketoacidosis, COPD Exacerbation or a bevy of other diseases both chronic and acute result in longer stays but rarely more than 5 - 7 days. Now remember (I know this should be self evident) once a patient is admitted to an ICU bed you cannot admit another patient to that bed until that patient is discharged or dies (a celestial discharge).

Critically ill Covid-19 patients occupy ICU beds for WEEKS and require incredible resources to keep them alive. This is a drag on the system and the morale of physicians, nurses, respiratory therapists and ancillary staff. The care these patients require and the steps healthcare workers must take to protect themselves are incomprehensible to the average person. If you have not done it or experienced it you just do not know. Once these patients are finally well enough to be discharged from the ICU they spend weeks on Step-Down Units or Floors and then spend even more time in Re-hab. The costs incurred by their families are insurmountable; only the very richest in our society can manage even with gold-plated health insurance policies! This is why I say ‘worse than death.’ Many of those we ’save’ would have foregone the saving if they knew what it would do to their family’s financial future and after all the suffering they endure. It is sad.

Well, Tom, I could go on but the point I am trying to make is that we need to make distinctions about this disease that talking about Infection and Mortality just do not get at. Covid-19 is a devastating disease and you do not want to become infected. Yes, most cases are mild (thankfully) and some people may not even know they were infected. But new research is now indicating that even Asymptomatic people may have unrecognized sequelae from the disease whose after effects may not be known for years.

Jude’s second email
Let me give you more of a flavor of what I am talking about. Critically ill Covid-19 patients require 24/7 one on one nursing care. If they are on a ventilator they require frequent ’suctioning’ of their breathing tube, if their kidneys have shut down they are on bedside dialysis (CRRT…Continuous Renal Replacement Therapy), they require turning side to side every 2 hours minimum to prevent skin breakdown, they are on multiple vasoactive IV medications running through continuous pumps, they have a feeding tube threaded through their nose into their small bowel and are receiving nutrition via the tube, they have large bore IV lines in their neck, the feedings lead to diarrhea so you are constantly dealing with loose stool until you put a containment device in their rectum…it goes on and on, so I am sure you get the picture. Now, remember in order for the nurse managing this patient to protect themselves they are wearing an N-95 mask or a helmet like CAPR device, they are wearing a plastic gown, they have a face shield on, they have booties on their shoes, the rooms are hot, they cannot leave the room sometimes for hours and when they do they are soaked in sweat head to toe and they do this for 12-14 hours day in and day out.

Now, if this patient is on ECMO (Extracorporeal Membrane Oxygenation) [think of it as ‘bedside’ cardiopulmonary bypass], then they require two on one nursing care!

Oh, and I forgot to mention, the patient is a 5 ft 5 in woman who weighs 275 lbs or a 6 ft 5 in man who weighs 350 lbs. Their girth extends side to side in the bed and requires at least two sometimes 3 or 4 people to turn them…and, God forbid you are ‘proning’ the patient; that might require 6 or 7 people.

Now, imagine doing that for the foreseeable future. It is grinding, overwhelming work that will take you to your knees. That is what is coming to the nurses at hospitals in FL, TX, AZ.

For these patients, well in order to keep them comfortable some of them require continuous Neuromuscular Blockade (chemical paralysis), continuous pain and sedation medications for weeks. Some of them do not wake up for days when you try to wean them from the ventilator. The neuromuscular blockade leads to something called ‘critical illness polyneuropathy’ which means they initially have little motor movement or strength and take a long time to just sit up much less raise their arms to feed themselves or walk.

And then you have the bills…

So, yes, I do believe there are some things worse than dying. When we put all of this in that box that says ‘Infected’ or ‘Recovered’ or ‘Died’ this is the type of thing you are talking about. 

Covid-19 is a horrid disease and you want to do everything you can to avoid it because you do not know if you have that chink in armor that lets it take you down. 


New cases jumped from 41,000 to 49,000 yesterday. Given that there were four days in mid-June during which new cases were under 25,000, this is a stunning increase. Unfortunately, this probably isn’t the end of it. My biggest question is when and how much it will increase the deaths numbers. Yesterday, the 7-day average of new deaths jumped to 5%, and that didn’t change today. But if we have more deaths numbers soon that come anywhere near 2,500 (yesterday’s level), then it’s inevitable deaths will increase at an even greater rate soon. This is something to watch closely.

The numbers
These numbers are updated every day, based on reported US Covid-19 deaths the day before (taken from the Worldometers.info site, where I’ve been getting my numbers all along). No other variables go into the projected numbers – they are all projections based on yesterday’s 7-day rate of increase in total Covid-19 deaths, which was 5%.

Note that the “accuracy” of the projected numbers diminishes greatly after 3-4 weeks. This is because, up until 3-4 weeks, deaths could in theory be predicted very accurately, if one knew the real number of cases. In other words, the people who are going to die in the next 3-4 weeks of Covid-19 are already sick with the disease, even though they may not know it yet. But this means that the trend in deaths should be some indicator of the level of infection 3-4 weeks previous.

However, once we get beyond 3-4 weeks, deaths become more and more dependent on policies and practices that are put in place – or removed, as is more the case nowadays - after today (as well as other factors like the widespread availability of an effective treatment, if not a real “cure”). Yet I still think there’s value in just trending out the current rate of increase in deaths, since it gives some indication of what will happen in the near term if there are no significant intervening changes.

Week ending
Deaths reported during week/month
Avg. deaths per day during week/month
Deaths as percentage of previous month’s
March 7
18
3

March 14
38
5

March 21
244
35

March 28
1,928
275

Month of March
4,058
131

April 4
6,225
889

April 11
12,126
1,732

April 18
18,434
2,633

April 25
15,251
2,179

Month of April
59,812
1,994
1,474%
May 2
13,183
1,883

May 9
12,592
1,799

May 16
10,073
1,439

May 23
8,570
1,224

May 30
6,874
982

Month of May
42,327
1,365
71%
June 6
6,544
935

June 13
5,427
775

June 20
4,457
637

June 27
6,272
896

Month of June
23,626
788
56%
July 4
 6,594
 942

July 11
6,933
990

July 18
 7,290
1,041

July 25
 7,664
1.095

Month of July
34,191
 1,103
145%
Total March – July
164,015


Red = projected numbers

I. Total deaths
Total US deaths as of yesterday: 127,649
Increase in deaths since previous day: 864
Yesterday’s 7-day rate of increase in total deaths: 5% (This number is used to project deaths in the table above; it was 5% yesterday. There is a 7-day cycle in the reported deaths numbers, caused by lack of reporting over the weekends from closed state offices. So this is the only reliable indicator of a trend in deaths, not the three-day percent increase I used to focus on, and certainly not the one-day percent increase, which mainly reflects where we are in the 7-day cycle).

II. Total reported cases
Total US reported cases: 2,504,676
Increase in reported cases since previous day: 49,010
Percent increase in reported cases since yesterday: 2%
Percent increase in reported cases since 7 days previous: 11%

III. Deaths as a percentage of closed cases so far in the US:
Total Recoveries in US as of yesterday: 1,068,768
Total Deaths as of yesterday: 127,649
Deaths so far as percentage of closed cases (=deaths + recoveries): 11% (vs. 11% yesterday)
For a discussion of what this number means – and why it’s so important – see this post.


I would love to hear any comments or questions you have on this post. Drop me an email at tom@tomalrich.com