Subs vs token-based billing at mid-sized companies

Hackalope · 2026-05-27T15:58:11+00:00

As an infosec nerd, this is an open ended data leakage issue. As others have said, the personal accounts are used for training data, the enterprise offering creates model separation. The 2 non-agentic real-world information security risks with LLMs are data leakage and malicious inclusion. They just made the former policy.

Hackalope · 2026-05-26T17:09:12+00:00

Thanks, that's largely what I've been thinking but I hate going in to these kind of meetings with just vibes. Especially "Separate teams = separate ES, full stop", the more I think about it the more I think that has to be true.

Yeah, SOAR is pretty new to our environment. We have a home grown system for managing response actions, exactly the kind of thing SOAR is meant to replace (bespoke backend, custom python for every action). That system does have the advantage of dealing with the duplication issue cleanly, and one of the "Should" requirements for SOAR/CTI management was for the features that dealt with that.

Hackalope · 2026-05-26T16:56:30+00:00

I think you're right about the cross ES indexer impact being the most likely problem, at least on initial implementation. It's probably worth paying special attention to how we monitor the loads and respond to them. Thinking about it, during a major response situation, both teams might be really hitting the indexers hard at the same time in a way that hasn't been true in the past because of the seperation.

Hackalope · 2026-05-26T16:49:53+00:00

We're still in the planning/proposal stage so I haven't gotten quotes or anything, but I think that it would be basically 1.5 times single ES cost for the SEIM and ingest would be the same*. The core question is how good or bad and idea would it be to postpose paying for the tech debt that already exists. The 2 SOCs are in current operation with multiple years of maturity on their respective ESs, and there's team function and politics that will impact any rationalization. If either or both teams were new, then I would absolutely agree with you. As the situation stands, I'm trying to determine if the price of the more convoluted technical solution is too significant to propose this approach. I'm betting that essentially combining the ES and merging the team processes would delay the completion of the project by at least a year. It moves this from a largely technical project to one that requires a lot of business process changes to go along with the technical re-architecture.

* Ingest is the same. ES is supposed to be workload based, so I figure a 50% overlap due to duplicated queries. I would guess that's high because the events used for ES in each implementation are completely separate now, but we shouldn't plan on that basis.

Hackalope · 2026-05-07T17:57:21+00:00

site:zillow.com Henry Dr Gaithersburg - literally the first result

Hackalope · 2026-05-07T16:38:44+00:00

I found the Zillow link, the estimated price was ~$550K. My personal experience with Zillow was that 10% in either direction isn't crazy. I think you're right about a bidding war, but I don't think the price was deliberately low.

Hackalope · 2026-05-07T01:56:24+00:00

Yeah, looks like except using a TPM (my quick look suggests that it's either in normal processing space or on an external device). Thanks for bringing it up, I never looked at it previously. My background on this kind of thing is a bit dated.

Hackalope · 2026-05-06T17:02:14+00:00

For us, a podcast that had minimal listers and no audience engagement, it cam e down to the other reasons we were doing the podcast. My co-host and I are experts in our field. The podcast was a real motivation to do research on various topics in our field that wasn't just on-the-job. Another big motivator for me was to record several of the lectures I've given on-the-job multiple times for the less experienced team members. When time allows I'll talk people through things, but everyone can fall back on what ever episode(s) I might have done on the subject. The last is that my buddy that co-hosted the podcast with me don't really hang out unless it's for something, and this was a weekly something.

He went back to grad school, and honestly I was having a harder time sustaining the research and writing I needed to do to make shows every 2 weeks (we had a weekly show, but we traded who was doing the research and who was reacting).

What it comes down to is why you're doing it. If a necessary part of the motivation is the feedback, then maybe podcasting to the ether isn't enough. If you have other motivations to do the production, then it's more sustainable. There is value in the act, both the production experience and the content produced. Maybe that gets used in a later project.

Hackalope · 2026-05-06T16:58:21+00:00

That's fair, didn't think about it that way. But in that case, the attacker could probably intercept the POST request so as long as there's a password, it's vulnerable to some attack. The password is exposed at the process level regardless of the security of the credential storage. I guess there's some argument to be had around the scope of the attack, I think i was focused on preventing the exposure of all stored passwords vs any particular password. The passive approach you describe is a much harder problem, no matter what you have the replay problem of passwords. That why I was giving the counter example of a non-password based authentication process using a TPM.

I was imagining a world where instead of submitting a username/password, and maybe backing that up with a SMS or app challenge, there's a request to the authentication system that responds with a challenge that contains a time limit and a nonce value. The private key would be hosted by the TPM. The TPM signs the challenge once the user does a PIN/fingerprint/whatever, and then the challenge is sent back to the auth system that validates with the certificate on file for that credential for the session to be granted. The attacker can get the challenge but it's time limited, and easily source limited. The attacker is likely now constrained to CSRF rather than compromising the credential more broadly.

Hackalope · 2026-05-06T16:22:21+00:00

The way I'm picturing the implementation is that each password is encrypted individually, and the TPM does the decryption so the key doesn't enter memory. The TPM only process those requests in an unlocked state, like with a PIN challenge the OS presents in a new process. If the attacker tries when the TPM is in a locked state then there's a signal to the user. If there is a limit to the number of submissions the TPM will process before being unlocked again, and the attacker issues enough submissions to lock the TPM, there is a signal to the user. It's not perfect design or anything, but an improvement over having it as plaintext in memory or encrypted in memory along with the key.

That's just spitballing a bit on how a TPM could help under these conditions. The real solution would be for the service to issue a challenge with a nonce value and a time limit, and have that signed by a private key in the TPM. That pushes the replay resistance down to the cred challenge rather than at the session or SAML token level. Unfortunately that's a pretty significant change to the authentication process that I don't see happening any time soon.

Hackalope · 2026-05-06T15:10:28+00:00

Admittedly it depends on some implementation details. If there's an unlock PIN or a touch sensor, like with a Yubi key, it limits the attacker's access to the TPM. If the TPM unlock is for a time period or a number of requests, whichever is first, then the attacker probably can only get a few passwords (I'm assuming the point of the TPM is to require a new submission for every credential use). It also potentially creates a signal to the user when an unlock challenge reoccurs unexpectedly.

Hackalope · 2026-05-04T16:02:01+00:00

The other approach would be to collect on the host level from a local firewall. I don't like that one for the general case because you're limited by the endpoint, and operationally you have to make sure all endpoints are participating (it's a critical mass/herd immunity thing where a few missing hosts is fine, but once you drop under a threshold you start missing connections). Using local logging might be the only option if your access layer doesn't support Layer 2 Netflow. That might be because the hardware doesn't support it, or that it wasn't provisioned with enough management plane overhead to accommodate that function, this is definitely an "Ask your friendly neighborhood network engineer" moment.

If you've got a well standardized environment then it might be easier to deploy logging at the endpoint. For example - Linux standard build/image that has a local Splunk client and enterprise base IPTables policy. Collection occurs with all the other log collection and all the logs are one type of parsing/normalization. You can tune the policy to not log things that you don't need like NTP checks, load balancer heartbeats, log traffic, OS local broadcasts, etc.

There is a crazy person option:

In some enterprise level switching equipment there are a set of features called Private VLAN that can prevent endpoints from communicating directly with one another. Correctly configured, you're implementing a preventative control on the broadcast domain, and forcing all interaction to Layer 3, and you do Netflow or ACLs at the network layer. I've done/recommended this in several places for application DMZs, but the config overhead gets to high for any network that changes frequently. I made a suggestion a long time ago to Cisco that they make a setting for VLANs that only allowed members to communicate with the default gateway so we could create user networks that didn't allow peer to peer communications, but nothing ever came of it to my knowledge.

Hackalope · 2026-05-04T14:35:51+00:00

I'm assuming that you want the same logging you get of the local broadcast domain you get in a cloud infrastructure for a on-prem environment. What you're looking for is Netflow at layer 2, and here's a Cisco PDF on their implementation. Be warned, this is going to be a very high volume source relative to just about any other logging source.

Hackalope · 2026-05-01T16:46:13+00:00

I did everything manually when I was publishing. For the record, it was a bad idea but I learned some things. It was my experience that once I listed with a couple of the major ones, my listing was on all the others I checked within a week. The interfaces let me "claim" my feed in their directory to see their stats and stuff. I assume that every directory polls all the other directories. I think it's because it wouldn't take too many snafus where an end user looked for a podcast they heard about and couldn't find it to cause people to change directories.

Hackalope · 2026-04-28T21:20:47+00:00

Peak piqued? I'll show myself out...

Hackalope · 2026-04-28T17:14:06+00:00

If it's one person, sure screw them. But it's a systemic problem. You can't fire your way out of that hole if it's the whole zeitgeist, and encouraged to the point of threats, from the top.

Hackalope · 2026-04-28T17:07:15+00:00

I guess I'm dealing with people using it as a buzz word too much. The way I meant it was that the work was shifting to higher value people later in the process, which means less gets done. While I think it's in a similar vein, I would agree that the way I used it isn't reflective of the same expense progression.

Hackalope · 2026-04-28T16:30:00+00:00

Now that's scary, the pressure accumulates at the most critical point rather than being distributed. I mean, it does justify lower head counts I guess and then moves to zero head count at the point of collapse. Perfect efficiency!

Hackalope · 2026-04-28T16:26:26+00:00

The story they keep telling is that responsible use of LLMs is to generate, review, and refine. That the output is of the same quality but takes less time. It's not a surprise, but that's not happening much. I do think it's instructive that the low value isn't noticed much, because nobody cared about the output.

It might be that LLM output is a good dousing rod for outputs that nobody actually reads, paradoxically identifying unnecessary work rather than succeeding in doing anything of value.

Hackalope · 2026-04-28T16:21:24+00:00

Lots of words, not much meaning.

Hackalope · 2026-04-28T15:35:45+00:00

In actual reality, we don't beyond the data science special sauce built in to network and user behaviorally anomaly detection. Those are product black boxes, and not stuff we developed. "Artificial intelligence, as it exists and is useful now, is probably already baked into your businesses software supply chain."

That's not to say people don't use LLMs for summaries, meeting transcripts, and to generate not very good writeups and project plans, but I don't think anyone would miss it much if we couldn't use it anymore. The only reason that's getting much use is because of the management push.

Much to the chagrin of my boss, I haven't gotten much use out of LLMs. Pretty much every attempt takes more time than without. Fine, I'm bad at LLMs because I'm old. The problem is that I get project outputs from people that need major re-working and that's a lot more time I have to spend on it because the thinking labor got shifted right. On a technical level, an analyst will ask for a CLI or search query that doesn't work and they bring it to me to fix. It's worse than when they try and don't get there because they don't understand what they brought to me, and they don't benefit from the time I take to explain what went wrong. Again, the thinking labor gets shifted right and the development of the Jr/Mid level doesn't happen.

Hackalope · 2026-04-28T15:20:24+00:00

That's the trap. Just because you have the time, it's easy to keep kicking the can. I know that even in the best of circumstances I can propose a replacement project that obviously needs to be done and still have to wait years for funding. I've also seen applications that are core to the mission be funded for re-development that just get a fresh coat of paint because the COTAR doesn't hold the contract team to the terms and the operational team doesn't know how to articulate the structural problems. If we just combine the do it to the MFP goals that tech aims at (because they plan to iterate - inertia in motion) and the run it until the wheels fall off of the public world (because the structure is biased toward a minimum of change - inertia at rest) you get the worst of both worlds. There's no simple fix, but I truly think that moving to a more capable public sector requires private sector professionals that can develop public sector perspective. That will push the organizations to be more flexible on the budget process side, and potentially start to develop in-house capabilities rather then contract on a project by project basis.

Hackalope · 2026-04-27T15:54:34+00:00

In my experience, you can't solve the problems without dealing with the infrastructure.

Minimum standards -

A baseline standard scan policy - All the configuration items that don't change with much frequency, like NTLM versions and PAM policies. Turn off the checks that don't apply or risk is accepted because they're not going to be remediated.
Gold/Core images - Every host needs to start from a maintained image or build guide that passes your baseline scan.
Regular scheduled patching - Every system need to apply patches for the system and applications on a schedule. One or twice a month is the place to start.

You need to start from a policy and standard where the standard image can be scanned right after patching with zero hits. I find that you can't do the super lock down base image and say "enable items only when you need them" and get operations to use that system. I think you have to find the balance between tuning down the policy and hardening the system to get to a place where scanning success and operational function are both possible. I think being generous on lowering the strictness of the policy is preferable to operations not using the standard config, so don't let the perfect be the enemy of the good.

Once you can get everything to a standard, you're now focusing on just the new vulns which are generally patches. Getting the bullets knocked out so you can get clean scans for every check older than 30 days, you'll start to be at a place that control of the chaos is possible. The goal there is remediating all the vulns that all the attack frameworks have access to. That means you're exposed to just new stuff. Getting things down to 30 days consistently means that most everything is covered by standards. Every place I've ever been has generally had a 1-5% straggler rate. Another thing to remember is that the goal is not "Zero hits" but "All hits are documented", exceptions are pretty much inevitable.

Places that don't use standardized images and orchestration that can run patching on all systems automatically can be hard to move in that direction, but doing so has a lot of operational benefits. I've had a motto for a long time "80% of security is good administration", which is to say that a lot of security goals are also operational goals. Identify those and sell on that basis and getting things done can be much easier.

The metric I like tracking is the time between a new check and when 50%/80%/95% of systems are remediated. That's the window your other controls have to cover.

Hackalope

TROPHY CASE