Hello? Is this thing on? Testing, testing... 123 testing

[Fraser Scott]

Hello!

So, it has been a while. But that's all changing now. The momentum is building. There is a shiny new website here:

https://threatspec.org/

It's not perfect, but it's miles better than the previous one IMO. Also, I've started reading The Art of Community (http://www.artofcommunityonline.org/) and

following some of the advise in that book, there is now a community section on the slowly expanding Wiki:

https://github.com/threatspec/docs/wiki

I'll shortly be adding some milestones, objects and goals, but in the meantime, here is the rough plan:

* Focus on threatspec-go. Get the tool working nicely, simplify installation etc, write some decent reporting tools and even a DFD generator.

* Find people interesting in trying threatspec-go. Work closely with an open source project to help them threat model their code. Maybe set up a blog to post

about the process.

* Grow the community. I've created a subreddit [1] for general discussions and sharing of useful links to do with all things threat modelling. Also, updates etc are being posted to the ThreatSpec twitter account [2].

You'll be hearing a lot more from here on here. In the meantime, I'd love to hear your thoughts and feedback etc.

Cheers!

[1] https://www.reddit.com/r/threatmodeling/

[2] https://twitter.com/ThreatSpec

[Fraser Scott]

On Wednesday, 22 February 2017 00:52:19 UTC, Fraser Scott wrote:

* Focus on threatspec-go. Get the tool working nicely, simplify installation etc, write some decent reporting tools and even a DFD generator.

Following on from a conversation I had with Chris, I thought it would make sense to expand on the idea of focusing on the Go parser. 

The idea was to pick one language to focus on, then to make the tools etc as awesome as possible for that language, to showcase the capabilities of code-driven threat modelling. By trying to do too many languages at once, there is a risk of not being able to test ideas quickly and consistently if everything is having to be replicated into different codebases. The only reason why I though Go would make sense is because we already have a parser and know that Go's callgraph utility should allow us to relatively easily generate dynamic Data Flow Diagrams - something which I think would be a key feature of ThreatSpec.

Having said that, it doesn't have to be Go. We also have a Python parser, so if it's easy to generate to generate callgraphs using Python, it would probably be quicker to experiment with Python rather than Go (for me at least because I use Python regularly these days). However, callgraphs in Python is a big unknown for me, I'd love input from others.

Finally, I'm doing a lot of AWS stuff these days, mostly through CloudFormation. I really, really like the idea of being able to threat model at the infrastructure layer. I'm wondering if this might be a good approach, because code-driven threat modelling seems to be a new concept anyway.. people might see it as an alternative to traditional AppSec, which it isn't. Doing something focused on Infrastructure-as-code might reduce the confusion, because as far as I know, there isn't really anything out there like AppSec for CloudFormation templates. I would imagine that you'd use ThreatSpec to define the trust boundaries and components in the CloudFormation templates, then those can be referenced in application code deployed to those components. Or something like that anyway.

So, do we focus on Go, Python or CloudFormation templates?

 

[Fraser Scott]

On Saturday, 25 February 2017 13:14:06 UTC, Fraser Scott wrote:

So, do we focus on Go, Python or CloudFormation templates?

An alternative approach would be to find an open source and security-critical project to partner with and base it around their language and needs. 

[Stephen de Vries]

IMO:

1. Cloudformation

2. Cloudformation

3. Cloudformation

4. Python

5. Go

;)

This is based purely on a guess of the type of users who want to invest the time in integrating ThreatSpec into their projects.  If you cast a net of all Cloudformation users, chances are you're going to catch many more threat modellers than if you cast a Go-net.  I haven't worked with cloudformation, but since it's all about the automation there might be scope to do more coolStuff(tm) in the future - maybe even auto-apply the threatspec mitigation to the template?  or trigger cloudwatch alerts automatically based on threatspec content.  

2p

--
https://threatspec.org
---
You received this message because you are subscribed to the Google Groups "threatspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to threatspec+unsubscribe@googlegroups.com.
To post to this group, send email to threa...@googlegroups.com.
Visit this group at https://groups.google.com/group/threatspec.
To view this discussion on the web, visit https://groups.google.com/d/msgid/threatspec/e6657c28-07e4-4f0b-a186-449ca18aae12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Stephen de Vries

CEO

+34 616 33 81 38  

@stephendv

[Fraser Scott]

On Sunday, 26 February 2017 08:03:46 UTC, Stephen de Vries wrote:

This is based purely on a guess of the type of users who want to invest the time in integrating ThreatSpec into their projects.  If you cast a net of all Cloudformation users, chances are you're going to catch many more threat modellers than if you cast a Go-net.  I haven't worked with cloudformation, but since it's all about the automation there might be scope to do more coolStuff(tm) in the future - maybe even auto-apply the threatspec mitigation to the template?  or trigger cloudwatch alerts automatically based on threatspec content.  

I think you're right about the net of CF users bringing more potential threat modellers than say Go because breaking into something "new" (Infrastructure as code) seems like it would be easier than breaking into something established (application code + AppSec). My only concern is the type of threat modelling you can do for CFT is somewhat more limited than application code (it's not turing complete etc.). You could definitely use CFT+ThreatSpec to define components and trust boundaries, and many of the AWS services can mitigate or expose certain threats (e.g. allowing iam:* would expose a privilege escalation), but you'd lose a lot of the threats people are used to seeing (SQL injection, XSS, CSRF etc).

Having said that, I spend 80% of my time at work in CloudFormation land, so could get traction there if it works well.

I posted to the Upspin mailing list last night. There is a Github issue about having a better defined security model, so I asked whether there was an appetite for code-driven threat modelling. I suspect there won't be much of a response (i think threat modelling is a hard sell in general), so if that goes nowhere perhaps CFT is the way to go....

https://groups.google.com/forum/#!topic/upspin/pfObC5lfjOE

[Fraser Scott]

On Sunday, 26 February 2017 09:04:03 UTC, Fraser Scott wrote:

On Sunday, 26 February 2017 08:03:46 UTC, Stephen de Vries wrote:

I posted to the Upspin mailing list last night. There is a Github issue about having a better defined security model, so I asked whether there was an appetite for code-driven threat modelling. I suspect there won't be much of a response (i think threat modelling is a hard sell in general), so if that goes nowhere perhaps CFT is the way to go....

Hmm, so it has been a few days now, and no significant reply. I've been thinking about the CloudFormation side of things, and there are some interesting things to note. Firstly, writing CFT (CloudFormations Templates) in JSON by hand sucks, and I discourage it generally. I tend to use the troposphere python tool to generate CFTs as you have the full power of python for loops, queries against live AWS etc. From a ThreatSpec point of view, this basically means threat modelling CFTs would be just a special case of threat modelling python, and we already have a python parser :)

The main difference with threat modelling python vs threat modelling CFTs via python would be any use of callgraphs to generate a DFD. We're not interested in the relationship between code (e.g. which class methods call others), but in the structure of the resulting CFT. Threat modelling CFTs is quite difficult because if you stick to just a static analysis, you'll possibly only see part of the picture, or alternatively you'd have to query AWS to get the full picture at which point it isn't really static and can quickly get complicated. I think the latter is probably the best approach, but in the meantime I thought that perhaps we could extend the language a little to allow people to express the relationship between boundaries/components.

For example.

  # @connects boundary @auth_service to @user_service

  # @connects boundary @user to @auth_service 

  # @connects component @app_subnets with @app_instances

In the above examples, SOURCE to DEST would be unidirectional, and SOMETHING with SOMETHING would be bidirectional. This could be used for cases whether callgraphs aren't straight forward.

Thoughts?

[Christopher Wood]

I like it. The more expressive, the better. Adding that to the Python
parser would be a breeze, too. I've no idea how CFTs look or work,
though. Maybe you could wire this stuff in and circulate it to the
list?

[Fraser Scott]

I like it. The more expressive, the better. Adding that to the Python
parser would be a breeze, too. I've no idea how CFTs look or work,
though. Maybe you could wire this stuff in and circulate it to the
list?

See the new topic :)