WEBVTT
00:00:03.839 --> 00:00:10.960
You probably have at least one system in your business right now that you trust completely and never think to double check.
00:00:11.679 --> 00:00:19.359
There's probably a vendor portal that tells you that everything's on schedule, or a regulatory alert feed that tells you that nothing's wrong.
00:00:19.600 --> 00:00:26.960
It could be an industry status page that you glance at once in a while and you never think about again because it's always been right before.
00:00:27.839 --> 00:00:31.280
Every organization has these trusted sources.
00:00:31.679 --> 00:00:34.799
Every trusted source eventually changes.
00:00:35.600 --> 00:00:43.600
The dangerous part here isn't that they change, it's actually that the organizations rarely notice when these changes happen.
00:00:46.240 --> 00:00:48.560
Sometimes it's a policy shift.
00:00:48.799 --> 00:00:51.039
Sometimes it's a system that fails.
00:00:51.280 --> 00:00:53.520
Or it could be that a market moves.
00:00:54.000 --> 00:00:56.640
Often leaders find out too late.
00:00:56.960 --> 00:01:02.240
The signal was there, but nobody turned it into something they could act on before the moment passed.
00:01:02.880 --> 00:01:07.599
What the hell happened is a weekly briefing for leaders who would rather be ready.
00:01:08.000 --> 00:01:09.280
I'm Michael Crack.
00:01:09.599 --> 00:01:12.159
I've spent over 30 years working in this situation.
00:01:12.560 --> 00:01:14.879
Planning gets interrupted by reality.
00:01:15.359 --> 00:01:20.959
This program looks at not just what the hell happened, but also what can be done about it.
00:01:25.439 --> 00:01:33.359
Right now, national security agencies are trying to untangle a massive, weeks-long breach of their primary intelligence platform.
00:01:33.760 --> 00:01:40.159
This is a system that never once threw an error code while hackers actually lived inside of it.
00:01:40.719 --> 00:01:50.400
This is a masterclass in how trust fails, and if you think that your vendor portals and regulatory feeds are immune from this type of attack, stick around.
00:01:50.640 --> 00:01:56.319
Because what broke at the federal level is likely sitting inside of your business today.
00:01:58.719 --> 00:02:01.200
Hold on to that thought for a second.
00:02:02.480 --> 00:02:07.599
Back in late May, or maybe it was early June, the timeline's still a little bit fuzzy.
00:02:08.000 --> 00:02:12.240
The exact same kind of trust failed at the federal level.
00:02:12.479 --> 00:02:26.159
Somebody got inside of the Homeland Security Information Network, the platform that federal, state, local, and even private sector partners use to share threat intelligence, and they also use it to coordinate security.
00:02:26.400 --> 00:02:30.400
Somebody got inside this system and they stayed there for weeks.
00:02:31.039 --> 00:02:43.120
Nobody noticed until the first days of July, and this was about the time when the system was being leaned on heavily to help coordinate security for the World Cup games that were currently underway across the country.
00:02:43.439 --> 00:02:50.879
DHS has confirmed this breach, and the hackers got into the HSIN servers and also a connected SharePoint system.
00:02:51.039 --> 00:02:54.960
This hasn't been attributed to any specific country or group yet.
00:02:55.199 --> 00:03:02.319
The Department of Homeland Security says that they've isolated the affected systems and that classified networks weren't touched.
00:03:02.560 --> 00:03:06.159
That the platform stayed operational the entire time.
00:03:07.280 --> 00:03:10.080
That last part is the key.
00:03:10.879 --> 00:03:14.800
The system never actually had to go down for something to be terribly wrong.
00:03:15.039 --> 00:03:31.280
During a hearing of the Senate Intelligence Committee, one senator simply put it like this The information on the Homeland Security Information Network isn't classified, but it is highly sensitive, and losing control of it puts national security at risk.
00:03:31.919 --> 00:03:42.479
Now normally this is where I'd spend a few minutes translating a government story into something that you would recognize maybe in your own building, but not this time, because you already recognize it.
00:03:42.800 --> 00:04:00.479
If your organization has ever leaned on a regulatory feed or a vendor status page or an industry alert system to tell you whether something's safe, then you are already running some smaller version of exactly this type of system that just failed at the Department of Homeland Security.
00:04:00.719 --> 00:04:07.199
So the question that we're going to carry into the next part of this podcast is not could this happen to me?
00:04:07.520 --> 00:04:12.960
Because it already has quietly, on a smaller scale and you probably didn't even notice.
00:04:13.520 --> 00:04:19.279
What's the one external source that your business treats as automatically true?
00:04:19.600 --> 00:04:30.079
And when is the last time that you checked on that source to see whether the source itself was still trustworthy, not just the information that it was providing to you?
00:04:30.319 --> 00:04:34.720
Nothing about this platform ever really looked broken, and that's the strange part.
00:04:34.959 --> 00:04:40.560
There were alerts that kept coming out, and information kept flowing, even with the alerts.
00:04:40.800 --> 00:04:43.759
What broke was something that nobody was watching for.
00:04:43.920 --> 00:04:48.720
It was the assumption that the platform itself was still trustworthy in the first place.
00:04:49.279 --> 00:04:59.120
Every agency that was pulling an alert off of the Homeland Security Information Network during these weeks wasn't looking at bad information because someone had lied to them.
00:04:59.360 --> 00:05:12.959
They were actually looking at a source that they had every reason historically to trust completely, but the source just completely and quietly stopped earning that trust, and nobody had rechecked that because nobody thought they needed to.
00:05:13.839 --> 00:05:15.759
This is not a data problem.
00:05:16.160 --> 00:05:18.879
This is more of a trust maintenance problem.
00:05:19.439 --> 00:05:25.199
And trust, once you've got it established, almost never gets re-examined on its own, and that's the problem.
00:05:25.439 --> 00:05:32.639
It just carries forward week after week until something forces the question or forces it to be challenged.
00:05:33.519 --> 00:05:35.360
Here's something that's interesting.
00:05:35.600 --> 00:05:44.399
People who spent decades studying intelligence have learned something that most organizations don't often teach to their employees or their trainees.
00:05:44.639 --> 00:05:50.240
They discovered that every piece of information requires two completely different judgments.
00:05:50.480 --> 00:05:53.600
The first one asks, can I trust this source?
00:05:54.000 --> 00:05:58.160
And the second one asks, is this particular information actually true?
00:05:59.120 --> 00:06:02.319
These may sound like the same question, but they're really not.
00:06:02.639 --> 00:06:11.680
Most organizations can answer the first question and they only have to answer it once, and then they spend years assuming that they've answered the second one as well.
00:06:12.399 --> 00:06:17.040
Here's the part that gets hard to separate and often never gets taught or trained on.
00:06:17.279 --> 00:06:27.759
When you decide to trust something, you're actually answering two different questions that I just mentioned before, and almost everybody collapses them into one single question.
00:06:28.079 --> 00:06:39.519
The first one asks about the source, about whether this information or this thing has been reliable before and looks at its track record to see if it's earned a benefit of the doubt.
00:06:39.839 --> 00:06:52.160
But it's that second question about what's in front of you right now or today, and whether or not that that specific piece of information is true regardless of who's handing it to you, where it's coming from.
00:06:52.639 --> 00:06:57.360
There are intelligence analysts that are trained to keep these two questions separate on purpose.
00:06:57.600 --> 00:07:04.720
Their training exists precisely because people have got them tangled without having this type of training.
00:07:05.199 --> 00:07:19.199
A source with a spotless history can still hand you something false, and a source that you've never even heard of, one that you'd have every reason to doubt, can occasionally hand you something that turns out to be exactly right or exactly accurate.
00:07:19.519 --> 00:07:29.040
The moment that you let a source's reputation answer the second question for you, you've stopped evaluating anything, and now you're just deferring information.
00:07:29.439 --> 00:07:33.839
That's the failure that's sitting beneath this problem with the Homeland Security Network.
00:07:34.000 --> 00:07:40.160
Every agency that was pulling information from that platform had a source with a track record.
00:07:40.800 --> 00:07:45.040
What they didn't have though was a running answer to the second question.
00:07:45.360 --> 00:07:49.759
Is this information or this specific thing right now still accurate?
00:07:50.000 --> 00:07:56.720
Because the first answer had been yes for so long that nobody thought to keep asking the second question.
00:07:57.279 --> 00:08:02.240
This isn't the first time that a trusted channel like this has carried something that it shouldn't have.
00:08:02.399 --> 00:08:20.720
Back in December of 2020 there was a company called Solar Wind, and they discovered that a piece of network monitoring software that was used by roughly 18,000 organizations that even included several federal agencies had been shipping with a backdoor that was built into it for months.
00:08:21.040 --> 00:08:26.399
The update was digitally signed and it came through the normal channels the way it always had.
00:08:26.639 --> 00:08:33.519
The companies that were running it weren't careless, they did exactly what all of us do with a vendor that we've used for years.
00:08:33.679 --> 00:08:37.120
They let the relationship stand in for the check.
00:08:37.759 --> 00:08:41.840
That's the pattern from both of the stories and the one that they share.
00:08:42.240 --> 00:08:50.480
This isn't one bad decision, it's actually a good decision that was made once, but then it quietly stopped getting remade.
00:08:52.480 --> 00:08:53.759
Here's some other examples.
00:08:53.919 --> 00:08:57.279
Think about your CPA or your outside attorney.
00:08:57.440 --> 00:09:01.200
Maybe it's your payroll provider or your HR platform.
00:09:02.240 --> 00:09:08.559
Could even be your bank or something like that, but nobody re-verifies these sources of information.
00:09:08.720 --> 00:09:15.919
Not because they're bad, but it's because information like this and these sources has been something that's earned your trust over time.
00:09:16.159 --> 00:09:17.600
And that's universal.
00:09:18.240 --> 00:09:24.080
There's an organizational reason that this keeps happening, and it's not that anyone's being careless.
00:09:24.399 --> 00:09:32.320
It's that most vendors and sources have vetting that happens once within an organization at the beginning of that relationship.
00:09:32.559 --> 00:09:37.840
This is when everyone is paying really close attention because the relationship is new and unproven.
00:09:38.159 --> 00:09:46.960
There are procurement that runs checks on the purchasing, there are legal reviews to the contract, and there are people who confirm the credentials.
00:09:47.200 --> 00:09:53.519
And then because that first pass was thorough, this source now gets treated as permanent and accepted.
00:09:53.840 --> 00:10:02.399
Nobody ever schedules a second look because scheduling a second look on something that's never failed feels like it's solving a problem that you don't really have.
00:10:02.639 --> 00:10:04.399
Feels like a waste of time.
00:10:05.200 --> 00:10:15.840
Sometimes I see a version of the same mistake and the responses that I have made on emergency management situations, and it's one of the first things that gets corrected early on in our area.
00:10:16.080 --> 00:10:28.000
Things like mutual aid agreements, resource list, maybe a contact roster for who's available during a disaster, none of that gets vetted only once and then filed away in a drawer somewhere.
00:10:28.320 --> 00:10:55.679
That information has to be revalidated on some sort of a cycle, either every planning period or every couple of months when the plan's reviewed, whether or not anything's gone wrong, because the alternative is to discover that there has been an error during an actual emergency and that the resource that we were counting on quietly stopped being available several months before possibly, and that nobody updated the list or checked to verify that it was still valid.
00:10:55.919 --> 00:10:59.679
The discipline part of this all isn't really distrust.
00:11:00.080 --> 00:11:06.960
It's just refusing to let we check this already be the answer for we checked this recently.
00:11:07.600 --> 00:11:14.080
That's the habit that the Homeland Security Network was missing, and that was at a scale that most of us will never operate at.
00:11:14.320 --> 00:11:22.720
It's also very likely the same exact habit that could be missing in somewhere in your organization on a much smaller scale right now.
00:11:22.960 --> 00:11:26.559
There's a name for this in the work that I do with private industry companies.
00:11:26.720 --> 00:11:34.240
I call it information hygiene, and the short version of this is that the information exists in different states.
00:11:34.399 --> 00:11:45.120
There's information that sometimes has been confirmed by a source that you trust, and some of it that you simply trust and assume is still true because it always has been.
00:11:45.679 --> 00:11:51.279
But most of the failures that I see or that I look at don't come from information that's gone missing.
00:11:51.440 --> 00:12:00.240
It comes from information or something that's been confirmed quietly and then slides into something that's merely assumed, with nobody noticing the slide.
00:12:00.480 --> 00:12:02.480
Think about what this might look like.
00:12:02.639 --> 00:12:09.039
I mentioned earlier that it could be a regulatory feed or a supplier portal, or maybe it's an industry alert system.
00:12:09.279 --> 00:12:14.799
You didn't do anything wrong in getting it set up, and that's what makes this so hard to catch.
00:12:15.039 --> 00:12:17.679
There's really no bad decision to point at.
00:12:17.840 --> 00:12:26.000
The failure here is in the ordinary human tendency to stop questioning something the longer that it's been a reliable source.
00:12:26.320 --> 00:12:35.279
The longer that a source has been right, the less likely that anyone will be to ask whether it's still the same source as it was when you first decided to trust it.
00:12:35.440 --> 00:12:37.519
So what does this all mean?
00:12:38.159 --> 00:12:44.080
It means that organizations that catch this before it costs them anything aren't running better technology.
00:12:44.320 --> 00:12:54.879
They've built an actual habit, they've put it on a calendar with a name attached to it, of going back and reverifying the sources that they've already decided to trust.
00:12:55.120 --> 00:12:58.960
Not the information coming out of the source, but the source itself.
00:12:59.440 --> 00:13:05.840
That's a different discipline than most risk programs are built for, and it's the one that this episode is really about.
00:13:06.799 --> 00:13:10.240
One thing worth saying directly because some of you are probably thinking it.
00:13:10.480 --> 00:13:13.200
I've spent thirty years in emergency management.
00:13:13.360 --> 00:13:16.320
That's emergency management, not cybersecurity.
00:13:16.480 --> 00:13:29.600
And I just walked you through a federal network breach, a software supply chain compromise, at least not in the way that people inside a security operations center or the IT center of these companies would know it.
00:13:29.840 --> 00:13:34.879
But here's what I do know, and this is the only thing that this show has ever actually been trying to sell.
00:13:35.279 --> 00:13:38.960
It's the pattern that exists beneath these type of systems.
00:13:39.200 --> 00:13:48.240
It's a trusted source or a track record that's standing in for a current check when nobody is there to re-verify because nobody thought they needed to.
00:13:48.639 --> 00:13:51.039
So it's not really a cybersecurity pattern.
00:13:51.120 --> 00:14:03.919
I've watched that exact shape show up in evacuation plans, mutual aid agreements, resource lists that look fine on paper, and then they fell apart the moment that somebody actually needed to use them.
00:14:04.480 --> 00:14:20.159
I spent years watching that type of failure repeat itself across situations with nothing else in common, and that's what's let me to walk into a story about a federal network that I've never heard of a few weeks ago and then tell you with real confidence what went wrong with it.
00:14:20.960 --> 00:14:29.360
This is also probably why you would consider bringing someone in from the outside rather than someone from the inside who knows your specific system.
00:14:30.240 --> 00:14:38.960
You already have the people who understand your vendor feeds or your supplier portals or your regulatory dashboards better than anyone outside ever will.
00:14:39.840 --> 00:14:48.080
But what most organizations don't have is someone that's trained specifically to see the shape of a trust failure before it becomes a headline.
00:14:48.559 --> 00:14:54.320
That's not really industry knowledge, it's more of a pattern recognition knowledge and understanding.
00:14:54.480 --> 00:15:03.440
And it travels into many rooms or operations center that I've never worked in before because what actually breaks is never really the technology.
00:15:03.600 --> 00:15:08.399
It's always the same type of habits that are missing in the same type of places.
00:15:08.639 --> 00:15:14.480
Most leaders who hear this story will walk away quietly and add another layer of monitoring to their systems.
00:15:14.639 --> 00:15:19.519
They'll add another dashboard or another alert that nobody has time to look at or read.
00:15:19.919 --> 00:15:23.919
None of that would have caught what happened at the Homeland Security Network.
00:15:24.240 --> 00:15:37.519
Preventing this assumption drift without burning a budget or creating a dedicated data watcher role boils down to automating the pulse checks and building a validation trigger into your existing workflows.
00:15:38.000 --> 00:15:44.000
If a piece of information rarely changes, you don't need to put a human being there to sit and stare at it.
00:15:44.240 --> 00:15:51.279
You just need to build a structural system that forces the information to verify itself when it actually matters.
00:15:51.600 --> 00:15:53.120
Let me give you four examples.
00:15:53.279 --> 00:16:00.159
These are low cost, low effort strategies that can help keep your confirmed data from turning into stale assumptions.
00:16:00.559 --> 00:16:04.559
First, set expiration dates on operational data.
00:16:05.120 --> 00:16:13.519
In IT and computer networking, data has a time to live, an automation clock that tags data with a hard expiration date.
00:16:13.759 --> 00:16:25.919
When the time to live period expires, the system doesn't necessarily delete the data but it simply flags it as now unverified, and it needs to be reconfirmed by the user before it can be used.
00:16:26.240 --> 00:16:29.679
Here's how to apply this without using dedicated staff.
00:16:29.919 --> 00:16:37.840
Instead of monitoring the data continuously, set an automated calendar or an alert that's tied to the data's risk level.
00:16:38.080 --> 00:16:42.559
For example, if it's a critical safety spec, it could be every six months.
00:16:42.720 --> 00:16:49.120
But if it's something more routine like policy documents, maybe it's not that regular, maybe it's yearly, or even every two years.
00:16:49.360 --> 00:16:55.039
The point being that it needs to be checked and set it to an automated calendar so it doesn't get forgotten.
00:16:55.679 --> 00:17:10.000
If there's a team member that relies on a certain piece of data that pops up then as marked unverified, they would be required to perform some kind of a check, a 30-second sanity check, or just a verification before they can act on it.
00:17:10.319 --> 00:17:15.839
So the data isn't monitored daily, but it is revalidated at the point of use.
00:17:16.480 --> 00:17:19.759
Another idea is to set trigger-based audit gates.
00:17:20.000 --> 00:17:28.319
Instead of checking data on a set timetable, you could tie the data re-verification to changes in the surrounding environment.
00:17:28.799 --> 00:17:37.759
The data you would usually degrade because something else shifted around it, either a system update or a vendor change, or maybe a tweak to one of your processes.
00:17:38.400 --> 00:17:46.960
So again, to apply this without dedicated staff, simply add a standard line item to an existing change management checklist.
00:17:47.200 --> 00:17:57.519
In other words, if we change step A, what legacy assumptions in step B or step C are we relying on that may no longer be true?
00:17:58.000 --> 00:18:00.559
Another idea would be tolerance bandwidths.
00:18:00.720 --> 00:18:08.799
If the data stays within normal operational parameters 99% of the time, then monitoring it manually is a waste of money.
00:18:09.119 --> 00:18:20.160
Instead, one option would be to set up automated thresholds or exception reporting that would only alert when a variable steps outside of historical baselines.
00:18:20.880 --> 00:18:32.079
To implement this suggestion without dedicated staff, simply use basic software automation tools like Excel scripts or system alerts that remain silent until a boundary is crossed.
00:18:32.319 --> 00:18:43.599
Then you ignore the data when it's behaving normally, but the moment that it drifts into an edge case or something on the fringe of what's acceptable, an automatic flag forces a pause.
00:18:44.559 --> 00:18:52.319
There are also things like kill switches or pre-mortems that you can use or that you can do to help minimize the risk.
00:18:52.559 --> 00:18:58.160
Changing the culture in your environment or your organization costs nothing to make adjustments to.
00:18:58.400 --> 00:19:04.240
One of the primary reasons that stale assumptions survive is because of confirmation bias.
00:19:04.400 --> 00:19:09.440
This is where people assume that just because something worked yesterday, it must still work today.
00:19:09.680 --> 00:19:15.279
So the next time before you launch a major project or execute a critical process, think of this.
00:19:15.519 --> 00:19:17.599
Run a 10-minute pre-mortem.
00:19:18.000 --> 00:19:29.920
Ask your team to assume that the project if the project fails catastrophically six months from now, what core assumptions did they make or did they take for granted that turned out to be wrong?
00:19:30.079 --> 00:19:38.559
This will force the team members to pull out old confirmed facts and ask, is this actually still true or are we just relying on memory?
00:19:42.640 --> 00:19:48.960
What actually catches this is smaller than what you would think, and it takes less time than the meeting that you probably sat through this morning.
00:19:49.200 --> 00:19:51.039
It's three simple steps.
00:19:51.440 --> 00:19:58.720
First, list every external source that your business treats as automatically true without a verification habit that's attached to it.
00:19:59.200 --> 00:20:04.960
Things like regulatory feeds or vendus vendor status pages or industry alert systems.
00:20:05.119 --> 00:20:12.720
Anything where you receive information and act on it because the source has always been good and accurate, not just because you checked it recently.
00:20:13.279 --> 00:20:16.880
Next, for each one of these, attach a name to it.
00:20:17.519 --> 00:20:29.359
Identify one person who's specifically responsible for that particular source, not just the information it delivers, but responsible to make sure that the source itself is verified and accurate.
00:20:30.640 --> 00:20:33.440
And finally, put a date on your calendar.
00:20:34.000 --> 00:20:37.119
Not a date that says we'll check when something feels off.
00:20:37.440 --> 00:20:39.279
An actual recurring date.
00:20:40.000 --> 00:20:48.480
Quarterly is probably going to be plenty, where a person re-verifies that the channel they're using is still what it was the day that they started using it.
00:20:49.279 --> 00:20:51.039
That's the entire exercise.
00:20:51.119 --> 00:20:55.680
There's no new software, no new headcount, no new vendor relationship.
00:20:55.920 --> 00:21:05.200
It's just a little bit of time to make a list, attach a name to it, and then pick a date and how often that that needs to be verified.
00:21:05.440 --> 00:21:08.079
Here's what it looks like depending on where you sit.
00:21:08.640 --> 00:21:15.359
In the healthcare vertical, it could be a regulatory or a public health alert feed that your team leans on the hardest.
00:21:15.599 --> 00:21:20.880
Find out who's responsible for confirming that the feed hasn't been altered upstream somewhere.
00:21:21.039 --> 00:21:24.960
And if the answer is nobody, then that's the first name to add.
00:21:25.680 --> 00:21:31.440
Maybe you work in manufacturing and it's a supplier status or an industry disruption alert.
00:21:31.680 --> 00:21:38.079
Someone needs to own reverifying that channel on a schedule, not just consuming whatever it says.
00:21:39.200 --> 00:21:46.960
Maybe you work in construction or infrastructure and it's a safety regulation or a notification system driving your operational decisions.
00:21:47.200 --> 00:21:55.519
Sometimes these could even be life safety decisions that nobody's ever asked is still the same channel as it was the day that you signed up for it.
00:21:56.319 --> 00:22:02.720
These are exactly the kind of blind spots that things like the Signal integrity assessment is built to surface.
00:22:03.599 --> 00:22:09.279
This is not to identify or say that your systems are broken because they're probably fine.
00:22:09.759 --> 00:22:19.680
But it does help to identify where nobody has specifically been looking at the difference between the information you've verified and the information that you've just got used to trusting.
00:22:20.319 --> 00:22:27.519
If this episode has made you a little bit uncomfortable about a source that you've never rechecked, then that discomfort is the whole point.
00:22:28.160 --> 00:22:33.440
Hopefully, this doesn't actually feel like a cyber episode because it wasn't intended to be that.
00:22:33.680 --> 00:22:36.559
Hopefully, it feels like an episode about maintenance.
00:22:37.200 --> 00:22:44.319
What I mean here is not equipment maintenance, but decision maintenance and trust maintenance and information maintenance.
00:22:45.279 --> 00:22:49.359
That's going to fit almost perfectly with how we can work on our resilience.
00:22:49.920 --> 00:22:53.279
So here's a quick recap of what we talked about in this episode.
00:22:54.000 --> 00:22:55.279
What the hell happened?
00:22:55.440 --> 00:23:02.400
A trusted government platform got quietly compromised for weeks and nobody noticed because the platform never stopped looking normal.
00:23:03.039 --> 00:23:04.480
What did this tell us?
00:23:04.799 --> 00:23:09.599
The most dangerous information failures aren't the ones where the data goes missing.
00:23:09.759 --> 00:23:17.119
They're the ones where a source that you've always trusted stops getting checked, and then nobody notices it the moment that it happens.
00:23:18.000 --> 00:23:19.759
What the hell can I do about it?
00:23:20.400 --> 00:23:33.680
You can list the sources that you treat as automatically true and name an owner for each one of these sources, and put a real date on when that source should be re-verified, not just the data that it's telling you.
00:23:35.039 --> 00:23:39.839
Remember that most failures that I study don't come from information that goes missing.
00:23:40.400 --> 00:23:48.559
The failures come from something that's confirmed and then quietly slides into something that becomes an assumption with nobody noticing that slide.
00:23:50.400 --> 00:23:54.720
Next week we'll try to stay close to the same territory because it's important.
00:23:55.200 --> 00:23:59.200
So if this one got under your skin a little, stick around and see how that's about.
00:23:59.680 --> 00:24:06.880
If you want the deeper version of this argument or discussion, check out the blue-to-gray newsletter that pairs with every episode.
00:24:07.440 --> 00:24:12.559
And this week's issue will go further on the information hygiene framework that we've talked about.
00:24:12.799 --> 00:24:16.720
And it'll also point to where we're headed next.
00:24:17.279 --> 00:24:18.799
I'm Mike McCracken.
00:24:18.880 --> 00:24:21.759
This is What the Hell Happened, and I'll talk to you next time.
00:24:21.920 --> 00:24:25.839
If you enjoyed this episode, drop me a comment or an email.
00:24:26.000 --> 00:24:27.519
It's in the show notes.
00:24:27.759 --> 00:24:29.119
I'd appreciate hearing from you.
00:24:29.200 --> 00:24:34.400
I'd also appreciate hearing any suggestions that you have for new ideas or new content.
00:24:34.559 --> 00:24:38.480
I'm always looking for things that will be exciting and interesting to listen to.
00:24:39.599 --> 00:24:44.720
What the Hell Happened is produced by Southwind Planning Solutions LLC.
00:24:45.279 --> 00:24:52.160
If this episode was useful, the Blue to Gray newsletter goes deeper into this and many other topics each week.
00:24:52.400 --> 00:24:55.200
You can subscribe for free on Beehive.
00:24:55.519 --> 00:24:57.279
The link is in the show notes.
00:24:57.920 --> 00:25:07.440
If you are sitting on an assumption that you have not verified in longer than you'd like to admit, or maybe there are other challenges where reality has interrupted your planning.
00:25:08.000 --> 00:25:11.519
There's a starting point for that in the show notes as well.
00:25:12.400 --> 00:25:18.400
You can find us on Apple Podcasts, Spotify, or anywhere else at ToListen Podcasts.
00:25:18.799 --> 00:25:26.720
You can also find me on LinkedIn and on our website at www.southwindplanning.com.
00:25:27.519 --> 00:25:29.119
I'm Mike McCracken.
00:25:29.519 --> 00:25:32.160
Thanks for listening, and I'll see you next time.
00:00:03.839 --> 00:00:10.960
You probably have at least one system in your business right now that you trust completely and never think to double check.
00:00:11.679 --> 00:00:19.359
There's probably a vendor portal that tells you that everything's on schedule, or a regulatory alert feed that tells you that nothing's wrong.
00:00:19.600 --> 00:00:26.960
It could be an industry status page that you glance at once in a while and you never think about again because it's always been right before.
00:00:27.839 --> 00:00:31.280
Every organization has these trusted sources.
00:00:31.679 --> 00:00:34.799
Every trusted source eventually changes.
00:00:35.600 --> 00:00:43.600
The dangerous part here isn't that they change, it's actually that the organizations rarely notice when these changes happen.
00:00:46.240 --> 00:00:48.560
Sometimes it's a policy shift.
00:00:48.799 --> 00:00:51.039
Sometimes it's a system that fails.
00:00:51.280 --> 00:00:53.520
Or it could be that a market moves.
00:00:54.000 --> 00:00:56.640
Often leaders find out too late.
00:00:56.960 --> 00:01:02.240
The signal was there, but nobody turned it into something they could act on before the moment passed.
00:01:02.880 --> 00:01:07.599
What the hell happened is a weekly briefing for leaders who would rather be ready.
00:01:08.000 --> 00:01:09.280
I'm Michael Crack.
00:01:09.599 --> 00:01:12.159
I've spent over 30 years working in this situation.
00:01:12.560 --> 00:01:14.879
Planning gets interrupted by reality.
00:01:15.359 --> 00:01:20.959
This program looks at not just what the hell happened, but also what can be done about it.
00:01:25.439 --> 00:01:33.359
Right now, national security agencies are trying to untangle a massive, weeks-long breach of their primary intelligence platform.
00:01:33.760 --> 00:01:40.159
This is a system that never once threw an error code while hackers actually lived inside of it.
00:01:40.719 --> 00:01:50.400
This is a masterclass in how trust fails, and if you think that your vendor portals and regulatory feeds are immune from this type of attack, stick around.
00:01:50.640 --> 00:01:56.319
Because what broke at the federal level is likely sitting inside of your business today.
00:01:58.719 --> 00:02:01.200
Hold on to that thought for a second.
00:02:02.480 --> 00:02:07.599
Back in late May, or maybe it was early June, the timeline's still a little bit fuzzy.
00:02:08.000 --> 00:02:12.240
The exact same kind of trust failed at the federal level.
00:02:12.479 --> 00:02:26.159
Somebody got inside of the Homeland Security Information Network, the platform that federal, state, local, and even private sector partners use to share threat intelligence, and they also use it to coordinate security.
00:02:26.400 --> 00:02:30.400
Somebody got inside this system and they stayed there for weeks.
00:02:31.039 --> 00:02:43.120
Nobody noticed until the first days of July, and this was about the time when the system was being leaned on heavily to help coordinate security for the World Cup games that were currently underway across the country.
00:02:43.439 --> 00:02:50.879
DHS has confirmed this breach, and the hackers got into the HSIN servers and also a connected SharePoint system.
00:02:51.039 --> 00:02:54.960
This hasn't been attributed to any specific country or group yet.
00:02:55.199 --> 00:03:02.319
The Department of Homeland Security says that they've isolated the affected systems and that classified networks weren't touched.
00:03:02.560 --> 00:03:06.159
That the platform stayed operational the entire time.
00:03:07.280 --> 00:03:10.080
That last part is the key.
00:03:10.879 --> 00:03:14.800
The system never actually had to go down for something to be terribly wrong.
00:03:15.039 --> 00:03:31.280
During a hearing of the Senate Intelligence Committee, one senator simply put it like this The information on the Homeland Security Information Network isn't classified, but it is highly sensitive, and losing control of it puts national security at risk.
00:03:31.919 --> 00:03:42.479
Now normally this is where I'd spend a few minutes translating a government story into something that you would recognize maybe in your own building, but not this time, because you already recognize it.
00:03:42.800 --> 00:04:00.479
If your organization has ever leaned on a regulatory feed or a vendor status page or an industry alert system to tell you whether something's safe, then you are already running some smaller version of exactly this type of system that just failed at the Department of Homeland Security.
00:04:00.719 --> 00:04:07.199
So the question that we're going to carry into the next part of this podcast is not could this happen to me?
00:04:07.520 --> 00:04:12.960
Because it already has quietly, on a smaller scale and you probably didn't even notice.
00:04:13.520 --> 00:04:19.279
What's the one external source that your business treats as automatically true?
00:04:19.600 --> 00:04:30.079
And when is the last time that you checked on that source to see whether the source itself was still trustworthy, not just the information that it was providing to you?
00:04:30.319 --> 00:04:34.720
Nothing about this platform ever really looked broken, and that's the strange part.
00:04:34.959 --> 00:04:40.560
There were alerts that kept coming out, and information kept flowing, even with the alerts.
00:04:40.800 --> 00:04:43.759
What broke was something that nobody was watching for.
00:04:43.920 --> 00:04:48.720
It was the assumption that the platform itself was still trustworthy in the first place.
00:04:49.279 --> 00:04:59.120
Every agency that was pulling an alert off of the Homeland Security Information Network during these weeks wasn't looking at bad information because someone had lied to them.
00:04:59.360 --> 00:05:12.959
They were actually looking at a source that they had every reason historically to trust completely, but the source just completely and quietly stopped earning that trust, and nobody had rechecked that because nobody thought they needed to.
00:05:13.839 --> 00:05:15.759
This is not a data problem.
00:05:16.160 --> 00:05:18.879
This is more of a trust maintenance problem.
00:05:19.439 --> 00:05:25.199
And trust, once you've got it established, almost never gets re-examined on its own, and that's the problem.
00:05:25.439 --> 00:05:32.639
It just carries forward week after week until something forces the question or forces it to be challenged.
00:05:33.519 --> 00:05:35.360
Here's something that's interesting.
00:05:35.600 --> 00:05:44.399
People who spent decades studying intelligence have learned something that most organizations don't often teach to their employees or their trainees.
00:05:44.639 --> 00:05:50.240
They discovered that every piece of information requires two completely different judgments.
00:05:50.480 --> 00:05:53.600
The first one asks, can I trust this source?
00:05:54.000 --> 00:05:58.160
And the second one asks, is this particular information actually true?
00:05:59.120 --> 00:06:02.319
These may sound like the same question, but they're really not.
00:06:02.639 --> 00:06:11.680
Most organizations can answer the first question and they only have to answer it once, and then they spend years assuming that they've answered the second one as well.
00:06:12.399 --> 00:06:17.040
Here's the part that gets hard to separate and often never gets taught or trained on.
00:06:17.279 --> 00:06:27.759
When you decide to trust something, you're actually answering two different questions that I just mentioned before, and almost everybody collapses them into one single question.
00:06:28.079 --> 00:06:39.519
The first one asks about the source, about whether this information or this thing has been reliable before and looks at its track record to see if it's earned a benefit of the doubt.
00:06:39.839 --> 00:06:52.160
But it's that second question about what's in front of you right now or today, and whether or not that that specific piece of information is true regardless of who's handing it to you, where it's coming from.
00:06:52.639 --> 00:06:57.360
There are intelligence analysts that are trained to keep these two questions separate on purpose.
00:06:57.600 --> 00:07:04.720
Their training exists precisely because people have got them tangled without having this type of training.
00:07:05.199 --> 00:07:19.199
A source with a spotless history can still hand you something false, and a source that you've never even heard of, one that you'd have every reason to doubt, can occasionally hand you something that turns out to be exactly right or exactly accurate.
00:07:19.519 --> 00:07:29.040
The moment that you let a source's reputation answer the second question for you, you've stopped evaluating anything, and now you're just deferring information.
00:07:29.439 --> 00:07:33.839
That's the failure that's sitting beneath this problem with the Homeland Security Network.
00:07:34.000 --> 00:07:40.160
Every agency that was pulling information from that platform had a source with a track record.
00:07:40.800 --> 00:07:45.040
What they didn't have though was a running answer to the second question.
00:07:45.360 --> 00:07:49.759
Is this information or this specific thing right now still accurate?
00:07:50.000 --> 00:07:56.720
Because the first answer had been yes for so long that nobody thought to keep asking the second question.
00:07:57.279 --> 00:08:02.240
This isn't the first time that a trusted channel like this has carried something that it shouldn't have.
00:08:02.399 --> 00:08:20.720
Back in December of 2020 there was a company called Solar Wind, and they discovered that a piece of network monitoring software that was used by roughly 18,000 organizations that even included several federal agencies had been shipping with a backdoor that was built into it for months.
00:08:21.040 --> 00:08:26.399
The update was digitally signed and it came through the normal channels the way it always had.
00:08:26.639 --> 00:08:33.519
The companies that were running it weren't careless, they did exactly what all of us do with a vendor that we've used for years.
00:08:33.679 --> 00:08:37.120
They let the relationship stand in for the check.
00:08:37.759 --> 00:08:41.840
That's the pattern from both of the stories and the one that they share.
00:08:42.240 --> 00:08:50.480
This isn't one bad decision, it's actually a good decision that was made once, but then it quietly stopped getting remade.
00:08:52.480 --> 00:08:53.759
Here's some other examples.
00:08:53.919 --> 00:08:57.279
Think about your CPA or your outside attorney.
00:08:57.440 --> 00:09:01.200
Maybe it's your payroll provider or your HR platform.
00:09:02.240 --> 00:09:08.559
Could even be your bank or something like that, but nobody re-verifies these sources of information.
00:09:08.720 --> 00:09:15.919
Not because they're bad, but it's because information like this and these sources has been something that's earned your trust over time.
00:09:16.159 --> 00:09:17.600
And that's universal.
00:09:18.240 --> 00:09:24.080
There's an organizational reason that this keeps happening, and it's not that anyone's being careless.
00:09:24.399 --> 00:09:32.320
It's that most vendors and sources have vetting that happens once within an organization at the beginning of that relationship.
00:09:32.559 --> 00:09:37.840
This is when everyone is paying really close attention because the relationship is new and unproven.
00:09:38.159 --> 00:09:46.960
There are procurement that runs checks on the purchasing, there are legal reviews to the contract, and there are people who confirm the credentials.
00:09:47.200 --> 00:09:53.519
And then because that first pass was thorough, this source now gets treated as permanent and accepted.
00:09:53.840 --> 00:10:02.399
Nobody ever schedules a second look because scheduling a second look on something that's never failed feels like it's solving a problem that you don't really have.
00:10:02.639 --> 00:10:04.399
Feels like a waste of time.
00:10:05.200 --> 00:10:15.840
Sometimes I see a version of the same mistake and the responses that I have made on emergency management situations, and it's one of the first things that gets corrected early on in our area.
00:10:16.080 --> 00:10:28.000
Things like mutual aid agreements, resource list, maybe a contact roster for who's available during a disaster, none of that gets vetted only once and then filed away in a drawer somewhere.
00:10:28.320 --> 00:10:55.679
That information has to be revalidated on some sort of a cycle, either every planning period or every couple of months when the plan's reviewed, whether or not anything's gone wrong, because the alternative is to discover that there has been an error during an actual emergency and that the resource that we were counting on quietly stopped being available several months before possibly, and that nobody updated the list or checked to verify that it was still valid.
00:10:55.919 --> 00:10:59.679
The discipline part of this all isn't really distrust.
00:11:00.080 --> 00:11:06.960
It's just refusing to let we check this already be the answer for we checked this recently.
00:11:07.600 --> 00:11:14.080
That's the habit that the Homeland Security Network was missing, and that was at a scale that most of us will never operate at.
00:11:14.320 --> 00:11:22.720
It's also very likely the same exact habit that could be missing in somewhere in your organization on a much smaller scale right now.
00:11:22.960 --> 00:11:26.559
There's a name for this in the work that I do with private industry companies.
00:11:26.720 --> 00:11:34.240
I call it information hygiene, and the short version of this is that the information exists in different states.
00:11:34.399 --> 00:11:45.120
There's information that sometimes has been confirmed by a source that you trust, and some of it that you simply trust and assume is still true because it always has been.
00:11:45.679 --> 00:11:51.279
But most of the failures that I see or that I look at don't come from information that's gone missing.
00:11:51.440 --> 00:12:00.240
It comes from information or something that's been confirmed quietly and then slides into something that's merely assumed, with nobody noticing the slide.
00:12:00.480 --> 00:12:02.480
Think about what this might look like.
00:12:02.639 --> 00:12:09.039
I mentioned earlier that it could be a regulatory feed or a supplier portal, or maybe it's an industry alert system.
00:12:09.279 --> 00:12:14.799
You didn't do anything wrong in getting it set up, and that's what makes this so hard to catch.
00:12:15.039 --> 00:12:17.679
There's really no bad decision to point at.
00:12:17.840 --> 00:12:26.000
The failure here is in the ordinary human tendency to stop questioning something the longer that it's been a reliable source.
00:12:26.320 --> 00:12:35.279
The longer that a source has been right, the less likely that anyone will be to ask whether it's still the same source as it was when you first decided to trust it.
00:12:35.440 --> 00:12:37.519
So what does this all mean?
00:12:38.159 --> 00:12:44.080
It means that organizations that catch this before it costs them anything aren't running better technology.
00:12:44.320 --> 00:12:54.879
They've built an actual habit, they've put it on a calendar with a name attached to it, of going back and reverifying the sources that they've already decided to trust.
00:12:55.120 --> 00:12:58.960
Not the information coming out of the source, but the source itself.
00:12:59.440 --> 00:13:05.840
That's a different discipline than most risk programs are built for, and it's the one that this episode is really about.
00:13:06.799 --> 00:13:10.240
One thing worth saying directly because some of you are probably thinking it.
00:13:10.480 --> 00:13:13.200
I've spent thirty years in emergency management.
00:13:13.360 --> 00:13:16.320
That's emergency management, not cybersecurity.
00:13:16.480 --> 00:13:29.600
And I just walked you through a federal network breach, a software supply chain compromise, at least not in the way that people inside a security operations center or the IT center of these companies would know it.
00:13:29.840 --> 00:13:34.879
But here's what I do know, and this is the only thing that this show has ever actually been trying to sell.
00:13:35.279 --> 00:13:38.960
It's the pattern that exists beneath these type of systems.
00:13:39.200 --> 00:13:48.240
It's a trusted source or a track record that's standing in for a current check when nobody is there to re-verify because nobody thought they needed to.
00:13:48.639 --> 00:13:51.039
So it's not really a cybersecurity pattern.
00:13:51.120 --> 00:14:03.919
I've watched that exact shape show up in evacuation plans, mutual aid agreements, resource lists that look fine on paper, and then they fell apart the moment that somebody actually needed to use them.
00:14:04.480 --> 00:14:20.159
I spent years watching that type of failure repeat itself across situations with nothing else in common, and that's what's let me to walk into a story about a federal network that I've never heard of a few weeks ago and then tell you with real confidence what went wrong with it.
00:14:20.960 --> 00:14:29.360
This is also probably why you would consider bringing someone in from the outside rather than someone from the inside who knows your specific system.
00:14:30.240 --> 00:14:38.960
You already have the people who understand your vendor feeds or your supplier portals or your regulatory dashboards better than anyone outside ever will.
00:14:39.840 --> 00:14:48.080
But what most organizations don't have is someone that's trained specifically to see the shape of a trust failure before it becomes a headline.
00:14:48.559 --> 00:14:54.320
That's not really industry knowledge, it's more of a pattern recognition knowledge and understanding.
00:14:54.480 --> 00:15:03.440
And it travels into many rooms or operations center that I've never worked in before because what actually breaks is never really the technology.
00:15:03.600 --> 00:15:08.399
It's always the same type of habits that are missing in the same type of places.
00:15:08.639 --> 00:15:14.480
Most leaders who hear this story will walk away quietly and add another layer of monitoring to their systems.
00:15:14.639 --> 00:15:19.519
They'll add another dashboard or another alert that nobody has time to look at or read.
00:15:19.919 --> 00:15:23.919
None of that would have caught what happened at the Homeland Security Network.
00:15:24.240 --> 00:15:37.519
Preventing this assumption drift without burning a budget or creating a dedicated data watcher role boils down to automating the pulse checks and building a validation trigger into your existing workflows.
00:15:38.000 --> 00:15:44.000
If a piece of information rarely changes, you don't need to put a human being there to sit and stare at it.
00:15:44.240 --> 00:15:51.279
You just need to build a structural system that forces the information to verify itself when it actually matters.
00:15:51.600 --> 00:15:53.120
Let me give you four examples.
00:15:53.279 --> 00:16:00.159
These are low cost, low effort strategies that can help keep your confirmed data from turning into stale assumptions.
00:16:00.559 --> 00:16:04.559
First, set expiration dates on operational data.
00:16:05.120 --> 00:16:13.519
In IT and computer networking, data has a time to live, an automation clock that tags data with a hard expiration date.
00:16:13.759 --> 00:16:25.919
When the time to live period expires, the system doesn't necessarily delete the data but it simply flags it as now unverified, and it needs to be reconfirmed by the user before it can be used.
00:16:26.240 --> 00:16:29.679
Here's how to apply this without using dedicated staff.
00:16:29.919 --> 00:16:37.840
Instead of monitoring the data continuously, set an automated calendar or an alert that's tied to the data's risk level.
00:16:38.080 --> 00:16:42.559
For example, if it's a critical safety spec, it could be every six months.
00:16:42.720 --> 00:16:49.120
But if it's something more routine like policy documents, maybe it's not that regular, maybe it's yearly, or even every two years.
00:16:49.360 --> 00:16:55.039
The point being that it needs to be checked and set it to an automated calendar so it doesn't get forgotten.
00:16:55.679 --> 00:17:10.000
If there's a team member that relies on a certain piece of data that pops up then as marked unverified, they would be required to perform some kind of a check, a 30-second sanity check, or just a verification before they can act on it.
00:17:10.319 --> 00:17:15.839
So the data isn't monitored daily, but it is revalidated at the point of use.
00:17:16.480 --> 00:17:19.759
Another idea is to set trigger-based audit gates.
00:17:20.000 --> 00:17:28.319
Instead of checking data on a set timetable, you could tie the data re-verification to changes in the surrounding environment.
00:17:28.799 --> 00:17:37.759
The data you would usually degrade because something else shifted around it, either a system update or a vendor change, or maybe a tweak to one of your processes.
00:17:38.400 --> 00:17:46.960
So again, to apply this without dedicated staff, simply add a standard line item to an existing change management checklist.
00:17:47.200 --> 00:17:57.519
In other words, if we change step A, what legacy assumptions in step B or step C are we relying on that may no longer be true?
00:17:58.000 --> 00:18:00.559
Another idea would be tolerance bandwidths.
00:18:00.720 --> 00:18:08.799
If the data stays within normal operational parameters 99% of the time, then monitoring it manually is a waste of money.
00:18:09.119 --> 00:18:20.160
Instead, one option would be to set up automated thresholds or exception reporting that would only alert when a variable steps outside of historical baselines.
00:18:20.880 --> 00:18:32.079
To implement this suggestion without dedicated staff, simply use basic software automation tools like Excel scripts or system alerts that remain silent until a boundary is crossed.
00:18:32.319 --> 00:18:43.599
Then you ignore the data when it's behaving normally, but the moment that it drifts into an edge case or something on the fringe of what's acceptable, an automatic flag forces a pause.
00:18:44.559 --> 00:18:52.319
There are also things like kill switches or pre-mortems that you can use or that you can do to help minimize the risk.
00:18:52.559 --> 00:18:58.160
Changing the culture in your environment or your organization costs nothing to make adjustments to.
00:18:58.400 --> 00:19:04.240
One of the primary reasons that stale assumptions survive is because of confirmation bias.
00:19:04.400 --> 00:19:09.440
This is where people assume that just because something worked yesterday, it must still work today.
00:19:09.680 --> 00:19:15.279
So the next time before you launch a major project or execute a critical process, think of this.
00:19:15.519 --> 00:19:17.599
Run a 10-minute pre-mortem.
00:19:18.000 --> 00:19:29.920
Ask your team to assume that the project if the project fails catastrophically six months from now, what core assumptions did they make or did they take for granted that turned out to be wrong?
00:19:30.079 --> 00:19:38.559
This will force the team members to pull out old confirmed facts and ask, is this actually still true or are we just relying on memory?
00:19:42.640 --> 00:19:48.960
What actually catches this is smaller than what you would think, and it takes less time than the meeting that you probably sat through this morning.
00:19:49.200 --> 00:19:51.039
It's three simple steps.
00:19:51.440 --> 00:19:58.720
First, list every external source that your business treats as automatically true without a verification habit that's attached to it.
00:19:59.200 --> 00:20:04.960
Things like regulatory feeds or vendus vendor status pages or industry alert systems.
00:20:05.119 --> 00:20:12.720
Anything where you receive information and act on it because the source has always been good and accurate, not just because you checked it recently.
00:20:13.279 --> 00:20:16.880
Next, for each one of these, attach a name to it.
00:20:17.519 --> 00:20:29.359
Identify one person who's specifically responsible for that particular source, not just the information it delivers, but responsible to make sure that the source itself is verified and accurate.
00:20:30.640 --> 00:20:33.440
And finally, put a date on your calendar.
00:20:34.000 --> 00:20:37.119
Not a date that says we'll check when something feels off.
00:20:37.440 --> 00:20:39.279
An actual recurring date.
00:20:40.000 --> 00:20:48.480
Quarterly is probably going to be plenty, where a person re-verifies that the channel they're using is still what it was the day that they started using it.
00:20:49.279 --> 00:20:51.039
That's the entire exercise.
00:20:51.119 --> 00:20:55.680
There's no new software, no new headcount, no new vendor relationship.
00:20:55.920 --> 00:21:05.200
It's just a little bit of time to make a list, attach a name to it, and then pick a date and how often that that needs to be verified.
00:21:05.440 --> 00:21:08.079
Here's what it looks like depending on where you sit.
00:21:08.640 --> 00:21:15.359
In the healthcare vertical, it could be a regulatory or a public health alert feed that your team leans on the hardest.
00:21:15.599 --> 00:21:20.880
Find out who's responsible for confirming that the feed hasn't been altered upstream somewhere.
00:21:21.039 --> 00:21:24.960
And if the answer is nobody, then that's the first name to add.
00:21:25.680 --> 00:21:31.440
Maybe you work in manufacturing and it's a supplier status or an industry disruption alert.
00:21:31.680 --> 00:21:38.079
Someone needs to own reverifying that channel on a schedule, not just consuming whatever it says.
00:21:39.200 --> 00:21:46.960
Maybe you work in construction or infrastructure and it's a safety regulation or a notification system driving your operational decisions.
00:21:47.200 --> 00:21:55.519
Sometimes these could even be life safety decisions that nobody's ever asked is still the same channel as it was the day that you signed up for it.
00:21:56.319 --> 00:22:02.720
These are exactly the kind of blind spots that things like the Signal integrity assessment is built to surface.
00:22:03.599 --> 00:22:09.279
This is not to identify or say that your systems are broken because they're probably fine.
00:22:09.759 --> 00:22:19.680
But it does help to identify where nobody has specifically been looking at the difference between the information you've verified and the information that you've just got used to trusting.
00:22:20.319 --> 00:22:27.519
If this episode has made you a little bit uncomfortable about a source that you've never rechecked, then that discomfort is the whole point.
00:22:28.160 --> 00:22:33.440
Hopefully, this doesn't actually feel like a cyber episode because it wasn't intended to be that.
00:22:33.680 --> 00:22:36.559
Hopefully, it feels like an episode about maintenance.
00:22:37.200 --> 00:22:44.319
What I mean here is not equipment maintenance, but decision maintenance and trust maintenance and information maintenance.
00:22:45.279 --> 00:22:49.359
That's going to fit almost perfectly with how we can work on our resilience.
00:22:49.920 --> 00:22:53.279
So here's a quick recap of what we talked about in this episode.
00:22:54.000 --> 00:22:55.279
What the hell happened?
00:22:55.440 --> 00:23:02.400
A trusted government platform got quietly compromised for weeks and nobody noticed because the platform never stopped looking normal.
00:23:03.039 --> 00:23:04.480
What did this tell us?
00:23:04.799 --> 00:23:09.599
The most dangerous information failures aren't the ones where the data goes missing.
00:23:09.759 --> 00:23:17.119
They're the ones where a source that you've always trusted stops getting checked, and then nobody notices it the moment that it happens.
00:23:18.000 --> 00:23:19.759
What the hell can I do about it?
00:23:20.400 --> 00:23:33.680
You can list the sources that you treat as automatically true and name an owner for each one of these sources, and put a real date on when that source should be re-verified, not just the data that it's telling you.
00:23:35.039 --> 00:23:39.839
Remember that most failures that I study don't come from information that goes missing.
00:23:40.400 --> 00:23:48.559
The failures come from something that's confirmed and then quietly slides into something that becomes an assumption with nobody noticing that slide.
00:23:50.400 --> 00:23:54.720
Next week we'll try to stay close to the same territory because it's important.
00:23:55.200 --> 00:23:59.200
So if this one got under your skin a little, stick around and see how that's about.
00:23:59.680 --> 00:24:06.880
If you want the deeper version of this argument or discussion, check out the blue-to-gray newsletter that pairs with every episode.
00:24:07.440 --> 00:24:12.559
And this week's issue will go further on the information hygiene framework that we've talked about.
00:24:12.799 --> 00:24:16.720
And it'll also point to where we're headed next.
00:24:17.279 --> 00:24:18.799
I'm Mike McCracken.
00:24:18.880 --> 00:24:21.759
This is What the Hell Happened, and I'll talk to you next time.
00:24:21.920 --> 00:24:25.839
If you enjoyed this episode, drop me a comment or an email.
00:24:26.000 --> 00:24:27.519
It's in the show notes.
00:24:27.759 --> 00:24:29.119
I'd appreciate hearing from you.
00:24:29.200 --> 00:24:34.400
I'd also appreciate hearing any suggestions that you have for new ideas or new content.
00:24:34.559 --> 00:24:38.480
I'm always looking for things that will be exciting and interesting to listen to.
00:24:39.599 --> 00:24:44.720
What the Hell Happened is produced by Southwind Planning Solutions LLC.
00:24:45.279 --> 00:24:52.160
If this episode was useful, the Blue to Gray newsletter goes deeper into this and many other topics each week.
00:24:52.400 --> 00:24:55.200
You can subscribe for free on Beehive.
00:24:55.519 --> 00:24:57.279
The link is in the show notes.
00:24:57.920 --> 00:25:07.440
If you are sitting on an assumption that you have not verified in longer than you'd like to admit, or maybe there are other challenges where reality has interrupted your planning.
00:25:08.000 --> 00:25:11.519
There's a starting point for that in the show notes as well.
00:25:12.400 --> 00:25:18.400
You can find us on Apple Podcasts, Spotify, or anywhere else at ToListen Podcasts.
00:25:18.799 --> 00:25:26.720
You can also find me on LinkedIn and on our website at www.southwindplanning.com.
00:25:27.519 --> 00:25:29.119
I'm Mike McCracken.
00:25:29.519 --> 00:25:32.160
Thanks for listening, and I'll see you next time.
