@public and python update from Chris

[Fraser Scott]

Fraser wrote:

> Ah, I'd forgotten about that flow diagram. I've made an updated version (attached), but I could probably do with uploading it to github.

> In terms of helping with the spec, go for it :) I think the file format is fine for now, and I've stopped adding stuff to the parsing format (@describe and multi-lines) so that

> should probably be 0.1.0 then. The tag spec docs are very rough, so feel free to edit them as you see fit. You know as much about ThreatSpec as I do :)

> I had one idea, but it probably makes sense to push it to a later version and to focus on docs, PR and parsers etc. I'll drop a post to the mailing list, but I thought it might be > good to mark tags as "public", to allow one to easily generate public facing threat models for non-open source stuff.

Chris wrote:

> Thanks! I'll start sketching the code to generate the threat model from the LAIR files. 

> As for your idea, that's awesome. That would be really useful for merging threat models across projects. A project could declare its public tags and, when the project is inhaled > or used by another, the parent would also inhale those tags. Is that what you had in mind?

Me again:

So, so that would be a general reporting tool written in python? If you want some inspiration, take a look at the html output stuff on threatspec.org - although there is tons of room for improvement.

The public thing I thought would be a new field in the LAIR spec. The question is, how would it fit into something like this:

    @mitigates @app:Crypto against @cwe_123_abc with something awesome (#666)

Something like this perhaps?

    @public @mitigates @app:Crypto against @cwe_123_abc with something awesome (#666)

Putting it at the front is nice because it makes it clear what is public and what isn't

Then a reporting tool could take a --public option to only generate a public-facing report, as you said possibly against multiple sub-projects.

Definitely feels like a 0.2.0 thing :)

FYI, that flow diagram is available here: http://threatspec.org/images/flow.png

[Christopher Wood]

Ah, I see. That's a cool feature and a simple extension to the grammar. Would it apply to every property (like aliases and descriptions)?

[Fraser Scott]

On Monday, 1 February 2016 22:14:11 UTC, Christopher Wood wrote:

Ah, I see. That's a cool feature and a simple extension to the grammar. Would it apply to every property (like aliases and descriptions)?

Wouldn't need to I think. The way the browser reporting works at the moment, it iterates over mitigations, exposures etc, so if they're public they'd need to pull in any information created using @alias or @describe. 

Thinking about it, I guess the danger there is that if you put something sensitive in there, e.g. via a @describe, then someone could expose that by making the wrong thing @public.. perhaps, maybe. But then again you don't want to have to mark a whole bunch of @alias and @describe's as @public just because you've made a change. 

[Christopher Wood]

That's right. You wouldn't want to accidentally disclose sensitive information by automatically sucking in a @description. To keep it simple, though, automatically using aliases and descriptions is probably the way to go. I get your point and agree that it'd be too much of a hassle to annotate everything with a @public. That's too much of a cognitive burden on the user, and that makes it far less likely to be used correctly (IMO).

[Fraser Scott]

The @description is basically only for threats, components and boundaries, so you'd probably not put anything really sensitive in there anyway. Anything particularly sensitive would probably end up in the MITIGATION part of a @mitigation anyway, and that is where you'd tag it as @public.

I'll create a GitHub issue for the feature.

[Fraser Scott]

On Thursday, 4 February 2016 09:14:27 UTC, Fraser Scott wrote:

I'll create a GitHub issue for the feature.

https://github.com/threatspec/specifications/issues/1