"Now It's Yours"

Jessy Lang: Welcome back to Security Dialogues. I'm Jessy, and this is episode ten. Nora Voss is back, product lead at a manufacturer of connected industrial equipment, and this time she isn't here to take our advisories apart. She's here because she needs something we've never talked about on this show: a vulnerability and compliance platform that runs inside her own network, because her customers' plants have no route to anyone else's cloud. Which makes tonight's question a practical one: is it fine to run this yourself? It's also why this week fits. TrustSource is releasing a Community Edition that you can run yourself. Tess has a story first, though, and it's the story that made Nora ask for this episode.

Tess Calder: A client of mine moved their vulnerability management platform in- house last year. Good reasons: data residency, and a regulator who wanted the inventory kept inside the country. Eight months later I'm on an engagement for them, and the first thing I find on the internal network is that platform. Fourteen months out of date. An admin account nobody had changed since installation. Reachable from every office subnet.

Marcus Hale: And inside it?

Tess Calder: Every known weakness in the company. Every asset, every owner, sorted by severity, with a helpful column for what's still unfixed. I didn't have to find a single vulnerability on that engagement. They had already filed all of them for me, in one place, neatly.

Nora Voss: That's the story I wanted you to tell. Because I'm about to build exactly that, and I'd like to know which part to be afraid of.

Jessy Lang: Marcus, Tess, Nora, this is where tonight starts.

— I. The Best Map in the Building —

Tess Calder: Most of what I do at the start of an engagement is build a map. Where things are, who owns them, what's weak. A vulnerability platform is that map, kept current by the defender's own scanners, with an owner field and a priority column. If I had to design the most useful single system for an attacker to find, I'd end up with something very close to it.

Marcus Hale: It's worth saying that nothing was wrong with the product in that story. The product did what it says it does. The version was old, the admin account was still on its install-day credentials, and the network placement was careless. Every one of those is an operations failure, not a product failure.

Nora Voss: So the lesson is don't run it yourself.

Tess Calder: The lesson isn't don't do it yourself. Running your own is a legitimate choice, and they had good reasons. The lesson is that they ran it like it was nobody's system. Either you run it properly, or you hand it to somebody who will. What you can't do is run it casually.

Marcus Hale: It wasn't on their asset list. Nobody was assigned to it. A project team installed it, the project closed, and the platform just carried on running, quietly, with nobody's name next to it.

Nora Voss: Projects end, and what they installed doesn't. I've inherited three of those. I usually found out when one of them broke.

— II. Why She Can't Use the Cloud Version —

Jessy Lang: Nora, why can't you just use the hosted version, the way most people would?

Nora Voss: Because of where my devices live and where my customers sit. Our equipment ends up in plants with no outbound route, by design. Validated networks, sometimes properly air-gapped. And the customer's contract says the asset list, which devices, which firmware versions, stays inside the plant. The moment I propose uploading that to somebody's cloud, the conversation ends. Not with an argument. With a polite no from a procurement office.

Tess Calder: So for you it isn't a preference.

Nora Voss: It's the entry ticket. If I can't run the tooling where the data is, I can't offer the service at all. We promised those customers that their inventory stays theirs, and we meant it.

Marcus Hale: I want to say this plainly, because it gets lost in the hosted- versus-self-hosted argument. That's a perfectly good reason, and it's a more common one than the industry admits. Regulated sectors, sovereignty rules, plant networks, defence suppliers. Self-hosting isn't the nostalgic option. For a lot of organisations it's the only one that exists.

Marcus Hale: But a legitimate reason isn't the same as a free pass. It means you've earned the right to do it yourself. It doesn't mean you've done it yet.

— III. Borrowed Trust —

Marcus Hale: Let me name what actually changes, because it's easy to describe as "now you have to do the work" and miss what the work replaces. With a hosted platform you borrow a great deal. The vendor patches it, hardens it, watches it, backs it up, and picks up the phone when something breaks at three in the morning. And you borrow the paperwork as well: the SOC 2 report, the ISO certificate. Call it borrowed trust.

Tess Calder: And it's the same shape as last week.

Marcus Hale: Exactly. Snapshot assurance. The report you lean on for a hosted tool is a photograph of the vendor's Tuesday. You're borrowing a snapshot, taken of someone else's operations, to cover a line in your own risk register.

Nora Voss: Is that bad?

Marcus Hale: No. It's a perfectly reasonable deal. It's called shared responsibility, and for most organisations it's the right one. Borrowing isn't the problem. Borrowing without knowing you're borrowing is. Most risk registers I read have no line that says we rely on the vendor's patch discipline. It's simply assumed.

Nora Voss: So when I self-host, that line moves.

Marcus Hale: It moves onto your side, in your own handwriting, where you can see it.

— IV. What You Take Back —

Nora Voss: Give me the real list. I want it itemised, not as a mood.

Marcus Hale: Updates, and testing the upgrade before it goes live. Backups, and separately, restores. Who holds admin. Network placement. Logging, and someone actually reading the logs. Capacity. Disaster recovery. And knowing when the vendor publishes a fix, which is an item of its own.

Nora Voss: That's eight. I run a service desk. I can price eight.

Tess Calder: It sounds like a lot until you notice it's the same list you already apply to every other system you run.

Nora Voss: Which I do. Badly, in places.

Tess Calder: Then the platform isn't adding a new kind of work. It's adding one more row to a table you already own.

Marcus Hale: And the table is the right place for it. The mistake in Tess's story wasn't doing the eight things badly. It was that this platform never got a row at all.

— V. The Honest Test —

Marcus Hale: So let me put the bar on the table, because this is where the conversation usually goes soft. Doing it yourself is fine. Doing it yourself properly means, at the very least, these seven things. A named owner and a deputy. An update path you've tested. A restore you've tested. Admin access that is narrow and watched. A network position that matches what the platform holds. Encryption, with the keys kept somewhere other than the data. And a way to hear about vendor fixes on the day they exist.

Tess Calder: And if you can't show me those seven, you're not self-hosting. You're abandoning it in place.

Nora Voss: That's harsh.

Tess Calder: It's what it looks like from the outside. From the inside it looks like a platform that's been perfectly fine for fourteen months.

Marcus Hale: And here's the part nobody says out loud. If you can't clear that bar, handing it to a professional isn't a failure of nerve. It's the better security decision. A provider who runs this for a hundred customers has a team on call, patches on a schedule, and has restored from backup more times than you will this decade. You're not buying a luxury. You're buying practice.

Nora Voss: So the choice isn't brave versus timid.

Marcus Hale: It's can-you-do-it-properly versus can't. Both answers are respectable. The only wrong answer is yes by default.

— VI. Keys, Access, and Distance —

Tess Calder: Back to my story, because the old version wasn't the whole gift. What made that platform so useful to me was what it held and where it sat. The map, in readable form, on the same network as everything it described, behind credentials from the same directory as everything else. I didn't have to break anything to read it. I only had to be someone.

Nora Voss: And mine would be worse. It won't hold one company's weak points. It will hold the weak points of devices installed at dozens of customers. If that leaks, it isn't one company's map. It's a map of every plant.

Marcus Hale: Then let's be honest about the three things that decide this. Encryption, keys, and access. Encryption first. Between the scanners, the agents and the platform, and at rest, in the database and in the backups. Disk encryption alone isn't the answer. It protects you from a stolen disk. It does nothing against an attacker with a valid login, or an admin account.

Tess Calder: And the keys are where people cheat without noticing. If the key sits on the same host as the encrypted data, readable by the same admin, you've built a locked door and taped the key to it.

Marcus Hale: It's the second lock from episode six. The platform's data is encrypted with a data key, and that key is wrapped by another key held somewhere else: a key management service, a hardware module, run by different people. Then a stolen database or a stolen backup is just unreadable noise. And you need to have rehearsed rotating that key, because a key you can't change is assumed permanence with a nicer name.

Nora Voss: And access?

Marcus Hale: Single sign-on through your identity provider, with a second factor. Roles that match jobs: most people need to see their own team's findings, not the whole map. Service accounts scoped to exactly what they scan and no more. One break-glass admin account, kept offline and alarmed, so that using it is an event. And the access logs read by a person, on a calendar.

Nora Voss: On a shop floor, people share logins. I know how that goes. I'd want to design it so sharing isn't the easy option.

Tess Calder: Then there's distance. Keep the map away from the territory. A management zone of its own, its own network segment, its own admin accounts that aren't the production domain's. If production falls, the map shouldn't fall with it in the same move.

Marcus Hale: That's the heart of it. A vulnerability platform is a list of reasons to attack you, with an index. Treat it with the care you'd give the list itself. Not near the system it describes, not inside it, and not under the same credentials.

Nora Voss: Which is easier in an air-gapped plant, in one way. And harder in another, because whoever carries the updates across is also carrying a way into the map.

Marcus Hale: Which is why the signed bundles matter. And this is the part that makes the bar a bar. Updates and backups are chores. Keys and access are where a wrong default turns into a breach. If you can't separate it, can't keep the keys elsewhere, can't run the access properly, that's exactly the moment to hand it to a provider whose whole business is that separation.

— VII. The Feed That Can't Reach You —

Nora Voss: There's a practical wrinkle nobody has mentioned yet. My plants have no outbound route. So how does a vulnerability platform find out about tomorrow's vulnerabilities?

Marcus Hale: Through data you bring to it. The platform is only as current as its last import: vulnerability records, exploitation data, advisories. In a hosted tool the vendor feeds it continuously and you never think about it. In an air-gapped one, somebody carries the update across the gap.

Tess Calder: Which turns the database itself into a snapshot. Same problem as last week, one layer down. The platform can look perfectly healthy, a green dashboard, and be answering with a three-month-old picture of the world.

Nora Voss: So the dashboard says no critical findings, and what it means is no critical findings as of the last import.

Marcus Hale: That's the sentence to put on the dashboard: as of. The date of the last import, visible, on every report. It costs nothing, and it turns a quiet lie into an honest statement.

Tess Calder: And think about the known-exploited list from the CVSS episode. An entry that lands after your last import is invisible to you. In the one category where freshness matters most.

Nora Voss: How often should we carry it?

Marcus Hale: Set it by what you're protecting. For plants, a weekly carry is realistic, with a faster path when something lands on the known-exploited list. The point isn't the exact number. It's that the number is written down, somebody owns it, and the date is on the screen.

Nora Voss: I can do a weekly carry. We already do a weekly firmware drop for the field team. It's the same van, metaphorically.

Tess Calder: One more thing about the carry. Whatever crosses that gap should be signed and checked on the way in, because the carrying path is itself a way in. A USB stick is an attack path with a very friendly purpose.

Marcus Hale: Signed bundles, checksums, and a scan before anything goes near the platform. It's ten minutes of procedure, and it's the same discipline you already apply to a firmware image.

Marcus Hale: There's a second thing hiding inside that import, and it's the bigger one. A platform that understands your software has to know the world your software lives in. Dozens of package ecosystems, thousands of components, every version, every licence, every advisory, every renamed package and withdrawn release. That knowledge changes every day. In a hosted tool, that's the vendor's burden. Self-hosted, the platform's own code is the smaller part of the update load. The knowledge is the larger part.

Nora Voss: So update the platform means two different things.

Marcus Hale: Update the software, monthly. Update the knowledge, continuously. Different cadence, and a different failure. Software goes stale visibly, because the version number tells on it. Knowledge goes stale silently.

Tess Calder: And parsers, too. New package formats, new lockfile versions. A platform that can't read a new lockfile doesn't shout. It reports no findings for a project it couldn't parse. A silent zero.

Nora Voss: What do I ask for, to catch that?

Marcus Hale: Ask whether the platform tells you what it couldn't read, and what the age of its knowledge is, on every report. Coverage next to findings. A zero is only worth something if you know what was looked at.

— VIII. Trust You Can Verify —

Marcus Hale: Here is what gets overlooked in that conversation. Owned trust has a property borrowed trust never has: you can check it. You can look up the version running today. You can see who logged in as admin last week. You can see exactly when the last update landed and who approved it. When an auditor asks how you know the platform is patched, your answer stops being the vendor's report says so, and becomes a log.

Tess Calder: From where I sit that's the real difference. With a hosted tool I can't tell you what's wrong with it, and neither can you. With one you run, the evidence is yours.

Nora Voss: So I trade a snapshot someone else took for a live feed I have to watch.

Marcus Hale: You trade a photograph for a window. You do have to look through it.

Tess Calder: And the window shows you the good news too. When the patching is on time, the logs say so, and that's worth more in an audit than any amount of borrowed paperwork.

— IX. A Fleet of One —

Nora Voss: This is the part that landed for me. I've spent twelve years telling people that publishing a fix isn't the same as the fleet running it. A third of my own installed base never took a critical update. And I've just realised that the platform I'm about to run is a fleet of one, with me as the customer who doesn't install the fix.

Tess Calder: That's a very honest sentence.

Nora Voss: It's a practical one. Who tells me there's a fix? How? How fast? What does it cost me to apply, in downtime and in revalidation? Who pays for that, and when?

Marcus Hale: Those are exactly the right four questions, and they're also the ones a vendor of a self-hosted product has to be ready to answer before you ask them.

Nora Voss: I've been on the other side of that exact conversation. Customers asking me what an update will cost them before they'll even read the release notes. I never thought I'd be the one asking.

— X. The Other Side of the Contract —

Marcus Hale: If you ship something people run themselves, you stop being a service and become a supplier, and the obligations change. Advisories that arrive on time, in a form a machine can read, so your tooling can tell you which versions need fixing. A statement, when a vulnerability in a dependency doesn't actually affect the product, so you don't burn a weekend on something that doesn't apply to you. A software bill of materials, so you can see what's inside before it lands on your network. A support window and an honest end-of-life date. And a way to report problems that reaches a real team.

Tess Calder: That last one is the PSIRT you've been talking about all month.

Marcus Hale: It's the same thing seen from the buyer's side. A self-hosted product with no vulnerability handling behind it is borrowed trust from someone who isn't offering any. That's worth knowing before you deploy, not after.

Nora Voss: So I should ask for those five things in the evaluation.

Marcus Hale: Ask any vendor, ours included. If the answers are vague, that's an answer.

Nora Voss: Good. I can put that in the tender. Procurement will love having something concrete to tick. And I'd add one thing from my own scars: ask how the advisory actually reaches me. I once discovered a distributor had never forwarded a single one of ours to the end customers. The advisory existed. Nobody who needed it ever saw it.

Marcus Hale: That's the same gap in the other direction. Publishing isn't delivering. A good vendor can show you the channel, and a good customer subscribes to it on day one, with a name next to the subscription.

Tess Calder: Just make sure someone reads what comes back.

— XI. Ten Minutes With a Red Team —

Tess Calder: Here's what I'd check first on any self-hosted security platform, because I'm going to check it anyway. One: where can I reach it from? It should be a handful of places, not every subnet. Two: who holds admin, and when did those credentials last change? Three: what version is it, compared with the newest? Four: what do its service accounts get to touch? It usually has read access to everything it scans. Five: where do the backups live, and who can read them?

Nora Voss: Five questions.

Tess Calder: Ten minutes. And it's most of what separates the client I described at the start from one I'd have trouble with.

Marcus Hale: And this is where two episodes back pays off. The asset tiers from the CVSS episode: decide what your own systems are worth before the number arrives. This platform belongs in tier one. It holds the map and it touches everything. Decide that before the first install, and most of Tess's five answers are already decided for you.

Tess Calder: Tier one means admin credentials with an owner, a narrow network path, and an update window that doesn't wait for a convenient quarter.

Nora Voss: I can do that. Tier one gets the same treatment my customers' safety-relevant units get. I know how to take something seriously when somebody has written down that it matters.

— XII. Who Owns It —

Marcus Hale: In the client story, nothing technical actually failed. It was a question of ownership. Projects end and systems don't. The platform was installed by a project team, and when the project closed, nobody inherited it.

Nora Voss: I've inherited three of those, and I can tell you what the handover document said each time. Nothing. It was a very short document.

Marcus Hale: So name an owner on day one. A person, not a team alias, with a calendar entry behind the name: a monthly update window, a standing path for emergency fixes, a quarterly restore test. A few hours a month.

Tess Calder: And a deputy. The single point of failure is usually the one person who knows how it works, and they go on holiday at exactly the wrong moment.

Nora Voss: So a service contract with myself. I can write one of those. I've written harder ones for customers.

Marcus Hale: Make it as boring as the ones you write for customers. That's the whole secret, honestly.

— XIII. What It Costs —

Tess Calder: Cost question, because nothing on this show is free.

Marcus Hale: It's real, and it's modest next to what people fear. Some infrastructure. A few hours a month of someone competent. An update window, and the discipline to actually use it. And the knowledge feed, which is the part of the load people forget to price. For a mid-size team, think a fraction of one person, not a new department. Against that you have a subscription that never ends and, for some organisations, a product they simply can't use.

Nora Voss: My arithmetic is simpler. Without it I can't sell the service to plants that won't send data out. The comparison isn't a hosted subscription. It's nothing.

Tess Calder: Same pattern we keep seeing. Security argues for it, but a customer requirement is what pays for it.

Nora Voss: My customers' procurement checklist has done more for your budget than any risk assessment I've ever written. I'm not complaining. It's a very efficient way to get a decision made.

Marcus Hale: It's a fine way to get a good outcome for the wrong reason, and I've stopped being precious about the reason.

— XIV. The Practised Update —

Marcus Hale: Rehearsed calm, once more. The update that goes smoothly on the day it matters is the one you rehearsed on a copy, on a boring afternoon. And the restore: a backup you've never restored is a rumour.

Nora Voss: I'm putting that on the wall in the service department.

Tess Calder: Do both on the same afternoon. Restore last night's backup onto a staging copy, then run the next update against it. That's your rehearsal, and it tells you whether either one works, while nothing depends on the answer.

Nora Voss: And if it doesn't work?

Marcus Hale: Then you found out on a Tuesday afternoon instead of during an incident. That's the cheapest possible way to learn it.

Nora Voss: That's also how I'd run a field update. I never thought of a service desk and a security team as the same kind of discipline, but here we are.

— XV. Choosing on Purpose —

Jessy Lang: So how does somebody listening actually decide? Self-host, or hand it to someone who does this for a living? Marcus, Tess, give them a way to decide.

Marcus Hale: I'll ask the questions, and Tess answers them the way she'd hear them from a client. One: is there a hard constraint? Data that may not leave, a network with no route out, a contract or a regulator that says so?

Tess Calder: If the answer is yes, the decision is already made. Your job is to do it well, or to find a professional who can run it inside your constraint.

Marcus Hale: Two: can you name the capacity to run it properly, honestly? A fraction of a person, and a calendar.

Tess Calder: If you can't name that person, hosted is the better deal, and there's no shame in it. A name on a calendar is the test. Good intentions aren't.

Marcus Hale: Three: can you tell the difference between what your vendor does for you and what you merely assume they do?

Tess Calder: That's the one I'd put first. Half the organisations I test that use hosted tools couldn't tell me what their vendor actually covers.

Nora Voss: Which means answering that question helps even if you never self- host.

Marcus Hale: That's why I like it. For each important hosted tool, write down the five things you're borrowing: patching, monitoring, backup, access control, incident response. Even if the answer is we borrow all five, and that's fine, it is now a decision instead of an assumption. And you can ask the vendor to confirm it in writing.

Nora Voss: And if they won't?

Marcus Hale: Then you've learned something about the deal, for the price of an email. There's also a middle option people forget. Somebody else operates it for you, inside your constraint, on your infrastructure or in a region you choose. You keep the control over where the data lives, and you borrow the practice. For a lot of teams that's the honest answer.

Tess Calder: Mixed is normal, too. Your tier list can decide it. Tier three tools hosted, happily, with someone else doing the patching. Tier one tools run by you, if you can clear the bar, because that's where you want the evidence to be yours.

Marcus Hale: I know a client in the energy sector who self-hosted for two years, then asked themselves those three questions honestly in a review, and moved back to a hosted setup. Nobody lost face. Their risk register got a line for what they were borrowing, the vendor confirmed the five things in writing, and the platform stopped being the thing their one engineer worried about on holiday.

Tess Calder: That's the part I like. They made the decision twice, on purpose.

Nora Voss: That's actually how I'd explain it to my board. Not hosted versus self-hosted. Which things do we borrow trust for, which things do we own it for, and did we choose both.

— XVI. Owned Trust —

Marcus Hale: So here is where I land. Borrowed trust isn't the villain, and owned trust isn't the hero. Both are deals. Borrowing is the right deal when you can't clear the bar yourself, and it's a good one when the provider does. Owning is the right deal when you must, or when you can honestly clear the bar, and it gives you evidence that's yours. The bad deal is the one nobody chose.

Tess Calder: Which is the unpatched platform. Nobody chose to run it badly. They just never chose.

Nora Voss: So I run it myself, because I have to, and I do it properly. And the parts I can't staff, round-the-clock monitoring, say, I buy from somebody who does it for a living.

Marcus Hale: That's a perfectly good answer. Own what you can do well, borrow the rest, and know which is which.

Nora Voss: Now it's mine, then. Fine. I've owned worse. At least this one I can log into.

Marcus Hale: The test hasn't changed. You can find it, you know who owns it, and you know which version it's on.

Tess Calder: Three questions. Most people can answer two.

— Outro —

Jessy Lang: Borrowed trust, and its sibling, owned trust. Neither is the answer on its own. The answer is choosing, and being honest about which one you can actually afford to do properly. I liked that Nora arrived wanting to self-host for the plainest reason there is: her customers will not accept anything else. And that she left with a plan for what she'll run herself and what she'll hand to a professional. If you've inherited a system nobody remembers installing, or you run a platform of your own and know exactly who owns it, or you handed one back to a provider and slept better, tell us. We read everything. Subscribe wherever you're listening to this, and leave us a rating if you've ever found the best map of your company sitting on an unpatched server. Next time: the homework nobody has time for. The threat model that always slips to next quarter, and what changes when it simply gets done, every time, without a four-hour meeting. Until then.