You should consider using local models instead of cloud ones. That both reduces the power you give to companies and your reliance on them remaining free.

Language translation is only as good as the data set. There's a ton of TS/js out there (and a lot of it is horrible) so LLMs tend to be able to spit out working js (but the security properties are at best questionable). They tend to be less good at python, and obscure things like lisp are more likely to just be totally wrong. (IMHO, the entire paradigm of having machines try to make code to be read by other machines is nonsense because code is for people. That's literally the point.)

This is also true for natural languages.

Finding things is really just about encodings, so if you're building something like a RAG then you kind of don't even need to bother with the inference. I've build half-RAGs before just to get semantic search and then just skip the inference part after I have my doc list.

This is, of course, less useful if you're looking for something on the internet and you don't have a local search engine. But I'm not sure that an LLM is better than just using a search engine. That's just my take, though. Perhaps I just haven't experienced it.

Yeah, there's definitely a bit more nuance. I think most folks can just skip LLMs, but there are some use cases in tech.

The thing about local models is that inference is cheap. They're trying to charge for inference to cover the cost of training, and training is what uses all the resources. If you refuse to pay for inference, then the economic model collapses. IMHO, that's the critical part.

Show up to the DMV with several million dollars and I guarantee you can find someone who let's you skip the test. Same deal.

I think one of the big problems with every methodology, and every attempt to come up with a unified vulnerability or threat ontology, is that a security problem can also be "whatever the user doesn't like." These types of things always run into problems caused by the mixing of syntactic and semantic threats, without attempting to distinguish between the two.

Then every threat library derived from these doomed ontologies end up either over complex or insufficiently complex to represent the problem set. At least that's my take. I could be wrong.

Adding in the VSM actually makes things a lot easier, because all your threats will align through viability. So then a threat can be more formally defined as "Any behavior systemic of the system under test that threatens the viability of the parent system, given that the behavior can be intentionally invoked."

The VSM also just happens to be a threat model, though it never seems to be described as such.

I'm reading "Brain of the Firm" and working on a threat modeling methodology, actually. I worked on one that's been used a bit internally at work. It allowed us to threat model before design. That provided a framework to guide design and support implementation, rather than just checking those things when they were done.

It has some similarities to Trike (at least as I understand it). That probably shouldn't be surprising since I worked for Mike Eddington for a while in the 2010's. It starts with something very similar to the trike requirements model, but isn't restricted to CRUD. It also added an additional "constraint" field which was free text. It was really powerful, but could be hard to use. One folks learned it, they were able to get great results. The best thing is that TPMs and product owners, not security folks, owned the first step. By including them in the process, the whole product team started to think in a more adversarial way. But it was always missing some stuff. The hardest thing is figuring out what level of abstraction to model. It also never had a good threat library.

Since digging into the Beer's Viable System Model, I think I've figured out a lot of additional things. There are still some gaps. All of this was happening before LLMs, and a lot of the manual work was mutating triplets. The whole thing was designed with formal language in mind (some folks suggested ACE). With LLMs the text manipulation is pretty easy, and formal language may not be necessary. Integrating VSM can clarify what level to model, while still providing recursion to model at a deeper level.

I'm also thinking about integrating the OODA loop. The whole idea of threat model then test has always been a problem for me. There's a natural interplay between your observations, how they fit in to what you know (orientation), which things you then prioritize to test (decide), and how you formulate your action into a hypothesis.

Ok but...

Here you go; https://theanarchistlibrary.org/library/erica-lagalisse-occult-features-of-anarchism

"Horizontalism" is definitely a core element of anarchist thought. I've also advocated for thinking in terms of consent.

I do think there's value in adversarial terminology, but there's also alienation.

It is important though to be a bit careful about radically redefining a bunch of terminology. Subcultures that do that tend to produce cults.

Also the "circle A" symbol comes from an anarchist Masonic lodge. It is rooted in European culture, but it's a little more complex than that. It's also connected to the occult, which includes both orientalist appropriations of Jewish symbolism as well as honest Integrations of traditional Jewish philosophy.

Yes, but it's very slow.

It's interesting that this doesn't talk about attacks on transformer cooling oil, or any kind of attacks on petroleum refinery or drilling equipment. Probably because the later would have been unthinkable in the 90's.