Пълният препис на The Platform Everyone Trusted

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.