Creating a DFD via mermaid

[Fraser Scott]

Will release the very very hacky code changes at some point (sorry Chris, your parser has been ruined), but for now just playing around:

https://www.linkedin.com/hp/update/6249710759417384960

> Me? Oh, I'm just using ThreatSpec to generate a DFD from code. Generating mermaid markdown from the threat model annotations. See https://lnkd.in/gEREgxD and https://threatspec.org/

[Stephen de Vries]

As per LinkedIn in comment: This looks very powerful! 

IMO the primary constraint for ThreatSpec adoption now for many orgs is go-only support.  From other threads it looks like python support is also in the works.... but even so, the Venn diagram of companies who: 

a) are willing to invest the time in threat modeling, because security is that important to them, 

and b) are using go or python - is not a huge group.

If you could allow threatspec to define the data flow in the annotations themselves as an alternative to using data flow analysis of the code - then you'd effectively have a language independent method of generating those diagrams.  The DFA for go and python could still be used as a first port of call - but if you're not using either of those then you could fall back to relying on the annotations.  That would immediately open up a much larger user base and free you from the hassle of having to build DFA support for the popular languages.

[Fraser Scott]

On Tuesday, 21 March 2017 11:30:16 UTC, Stephen de Vries wrote:

As per LinkedIn in comment: This looks very powerful! 

Thanks :)

 

IMO the primary constraint for ThreatSpec adoption now for many orgs is go-only support.  From other threads it looks like python support is also in the works.... but even so, the Venn diagram of companies who: 

a) are willing to invest the time in threat modeling, because security is that important to them, 

and b) are using go or python - is not a huge group.

It's a tough balance I think. On the one hand, we don't want to be spread too thin by trying to support as many languages as possible. On the other hand, picking one language limits the pool of possible early adopters. I think it still makes sense to focus on the "sales pitch" in order to get those early adopters interested. Ie pick one appropriate language, and make an awesome tool for that language.  

If you could allow threatspec to define the data flow in the annotations themselves as an alternative to using data flow analysis of the code - then you'd effectively have a language independent method of generating those diagrams.  The DFA for go and python could still be used as a first port of call - but if you're not using either of those then you could fall back to relying on the annotations.  That would immediately open up a much larger user base and free you from the hassle of having to build DFA support for the popular languages.

Hmm, are you suggesting a language agnostic parser that just looks for the tags (@connects, @mitigates etc) in any file? That would be sort of like the hacky ruby script I originally had that parsed Go source files. Interesting.

[step...@gmail.com]

Hmm, are you suggesting a language agnostic parser that just looks for the tags (@connects, @mitigates etc) in any file? That would be sort of like the hacky ruby script I originally had that parsed Go source files. Interesting.

Ya!  If it could parse any text file then it won't just be language independent it would be technology independent too, so you could create a ThreatModel.md as part of the docs - or on a wiki and it would be parseable (or I guess in cloudformation too?).  Even parsing .docx should be quite straightforward.

 

[Fraser Scott]

On Thursday, 23 March 2017 08:16:28 UTC, step...@gmail.com wrote:

Ya!  If it could parse any text file then it won't just be language independent it would be technology independent too, so you could create a ThreatModel.md as part of the docs - or on a wiki and it would be parseable (or I guess in cloudformation too?).  Even parsing .docx should be quite straightforward.

Ah cool! In which case, done :)

    $ ./universal.py ../report_dfd/example.py > ../report_dfd/threatspec.json 

    ...

    $ ./mermaid.py threatspec.json

    graph LR

        classDef exposures fill:#e74c3c,stroke:#333,stroke-width:2px;

        classDef mitigations fill:#2ecc71,stroke:#333,stroke-width:2px;

        classDef transfers fill:#9b59b6,stroke:#333,stroke-width:2px;

        classDef acceptances fill:#f39c12,stroke:#333,stroke-width:2px;

        classDef reviews fill:#3498db,stroke:#333,stroke-width:2px;

        subgraph Web / ELB

            web_loadbalancers("Load balancers")

        end    

It's basically just a wrapper around _parse_comment, so will match any line that matches the pattern:

        comments = ['//', '/*', '#', '"""', '\'\'\'']

        tags = ['alias','describe','connects','review','mitigates','exposes','transfers','accepts']

        self.parser.node_regex = "^\s*(?:{})*\s*@(?:{}).*$".format('|'.join(map(lambda c: re.escape(c), comments)), '|'.join(map(lambda t: re.escape(t), tags)))

My plan for this week is to get these code changes pushed to git.

[Fraser Scott]

Just to clarify, it's parsing a python file above, but just treating it as a text file. It could be example.go, example.rb or anything really.

The downside is that we lose some of the metadata, namely the function/class that the ThreatSpec tag relates to, leaving us with something like this instead:

            "function": "universal",

            "type": "uni",

            "lineno": 23,

            "fname": "../report_dfd/example.py"

Could be worse of course, especially that we can now use @connects to build DFDs rather than relying on the languages' callgraphs.