Jonathan Marcil’s Threat Modeling Toolkit talk

There’s a lot of threat modeling content here at AppSec Cali, and sadly, I’m only here today. Jonathan Marcil has been a guest here on Adam & friends, and today is talking about his toolkit: data flow diagrams and attack trees.

His world is very time constrained, and it’s standing room only.

  • Threat modeling is an appsec activity, understand attackers and systems
  • For security practitioners and software engineers. A tool to help clarify what the system is for reviewers. Highlight ameliorations or requirements.
  • Help catch important things despite chaos.
  • Must be collaborative: communication is a key
  • Being wrong is great: people get engaged to correct you!
  • Data flow diagrams vs connection flow diagrams: visual overload. This is not an architectural doc, but an aid to security discussion. He suggests extending the system modeling approach to fit your needs, which is great, and is why I put my definition of a DFD3 on github; let’s treat our tools as artifacts like developers do.
  • An extended example of modeling Electrum.
  • The system model helps organize your own thoughts. Build a visual model of the things that matter to you, leave out the bits that don’t matter.
  • Found a real JSONRPC vuln in the wallet because of investigations driven by system model.
  • His models also have a “controls checklist;” “these are the controls I think we have.” Controls tied by numbers to parts of diagram. Green checklists are a great motivator.
  • Discussion of one line vs two; would another threat modeling expert be able to read this diagram? What would be a better approach for a SAML-based system? Do you need trust boundaries between the browser and the IDP? What’s going through your head as you build this?
  • Use attack trees to organize threat intelligence: roots are goals, leafs are routes to goals. If the goal is to steal cryptocurrency, one route is to gain wallet access, via stealing the physical wallet or software access. (Sorry, I’m bad at taking photos as I blog.) He shows the attack tree growing in a nice succession of slides.
  • Attack trees are useful because they’re re-usable.
  • Uses PlantUML to draw trees with code, has a bunch of advantages of version control, automatically balancing trees.
  • Questions: How to collaborate with and around threat models? How to roll out to a group of developers? How to sell them on doing something beyond a napkin.
  • Diagrams for architects versus diagrams for developers.
  • If we had an uber-tree, it wouldn’t be useful because you need to scope it and cut it. (Adam adds: perhaps scoping and cutting are easier than creating, if the tree isn’t overwhelming?)
  • Link attack tree to flow diagram; add the same numbered controls to the attack tree.
  • If you can be in a meeting and say nothing in the TM meeting, you’ve won!

Lastly, Jonathan did a great job of live-tweeting his own talk.

AppSec Cali 2018: Izar Tarandach

I’m at the OWASP AppSec Cali event, and while there’s now there’ll be video, I’m taking notes:

Context for the talk

  • What fails during the development process? Incomplete requirements, non-secure design, lack of security mindset, leaky development
  • These failures are threats which can be mitigated. (eg, compliance and risk requirements address incomplete requirements)
  • We keep failing in the same way. How often are developers required to pass a security interview to get a job?
  • Story of Alice the manager, and Bob the developer who learns about a SQL injection in their legacy code. Bob is overwhelmed by security requirements.
  • “The problem with programmers is that you can never tell what a programmer is going until it is too late.” — Seymour Cray
  • Security team objective: be informed about product flow; help developers not write and not deploy security issues; stop being a bottleneck; so focus secure development on the developer, not the security expert.

Notable Security Events

  • How to integrate security expertise into development in a more fluid way. Does this tie to “the spec”?
  • Developers don’t know that their changes are security relevant
  • Funny example of a training quiz that doesn’t have a learning goal
  • Noel Burch’s hierarchy of competence. From unconscious incompetence through unconscious competence.
  • Learning: step-by-step, instructions, theory; training: repetition, muscle memory; applying: real life doing.
  • Tie domains to notable events, use checklists for those notable events.
  • Specifically formed “if you did X, do Y.” Each “Y” must be in the language of the developer, concise, testable, and supported by training.
  • Ran an experiment, got solid feedback.
  • Short training gets used more.
  • Crisply defined responsibilities by role.

This is very cool: “Star Trek’s secret weapon: a scientist with a mushroom fetish bent on saving the planet.”

On Star Trek: Discovery, the character Lieutenant Paul Stamets is an “astromycologist” — a mushroom expert in outer space who is passionate about the power of fungi.

Stamets is actually named after a real U.S. scientist who spends his downtime tramping through the forests of B.C.’s Cortes Island.

The real Stamets has a few books. “Mycelium Running” is a fascinating read.

What’s more primordial than fire? It’s easy to think that fire is a static threat, and defenses against it can be static. So it was surprising to see that changes in home design and contents are leading to fires spread much faster, and that the Canadian Commission on Building and Fire Codes is considering mandates for home sprinklers.

The CBC’s “Rise in fast-burning house fires heats up calls for sprinklers in homes” has a good discussion of the changing threat, the costs of mitigation, and the tradeoffs entailed.

In a memo issued Jan. 4 and rescinded about an hour later, Deputy Defense Secretary Pat Shanahan announced a new “Central Cloud Computing Program Office” — or “C3PO” — to “acquire the Joint Enterprise Defense Infrastructure (JEDI) Cloud.”

“C3PO is authorized to obligate funds as necessary in support of the JEDI Cloud,” Shanahan, a former Boeing Co. executive, wrote, managing to get a beloved droid from the space-themed movies and an equally popular fictional order of warriors into what otherwise would be a routine message in the Pentagon bureaucracy.

The memo was recalled because “it was issued in error,” according to Shanahan’s spokesman, Navy Captain Jeff Davis.

Thanks to MC for the story.

The Resistance Has Infiltrated This Base!

“[Mukhande Singh] said “real water” should expire after a few months. His does. “It stays most fresh within one lunar cycle of delivery,” he said. “If it sits around too long, it’ll turn green. People don’t even realize that because all their water’s dead, so they never see it turn green.”
(Unfiltered Fervor: The Rush to Get Off the Water Grid, Nellie Bowles, NYTimes, Dec 29, 2017.)
So those things turning the water green? Apparently, not bugs, but features. In unrelated “not understanding food science” news, don’t buy the Mellow sous vide machine. Features.

Not Bugs, but Features

Pen Testing The Empire

[Updated with a leaked copy of the response from Imperial Security.]

To: Grand Moff Tarkin
Re: “The Pentesters Strike Back” memo
Classification: Imperial Secret/Attorney Directed Work Product


We have received and analyzed the “Pentesters Strike Back” video, created by Kessel Cyber Security Consulting, in support of their report 05.25.1977. This memo analyzes the video, presents internal analysis, and offers strategies for response to the Trade Federation.

In short, this is typical pen test slagging of our operational security investments, which meet or exceed all best practices. It is likely just a negotiating tactic, albeit one with catchy music.

Finding 1.3: “Endpoints unprotected against spoofing.” This is true, depending on a certain point of view. Following the execution of Order 66, standing policy has been “The Jedi are extinct. Their fire has gone out of the universe.” As such, Stormtrooper training has been optimized to improve small arms accuracy, which has been a perennial issue identified in after-action reports.

Finding 2.1: “Network Segmentation inadequate.” This has been raised repeatedly by internal audit, perhaps this would be a good “area for improvement” in response to this memo.

Finding 4.2: “Data at rest not encrypted.” This is inaccurate. The GalactiCAD server in question was accessed from an authorized endpoint. As such, it decrypted the data, and sent it over an encrypted tunnel to the endpoint. The pen testers misunderstand our network architecture, again.

Finding 5.1: “Physical access not controlled.” Frankly, sir, this battle station is the ultimate power in the universe. It has multiple layers of physical access control, including the screening units of Star Destroyers and Super SDs, Tie Fighters, Storm Trooper squadrons in each landing bay, [Top Secret-1], and [Top Secret-2]. Again, the pen testers ignore facts to present “findings” to their clients.

Finding 5.2: “Unauthorized mobile devices allows network access.” This is flat-out wrong. In the clip presented, TK-427 is clearly heard authorizing the droids in question. An audit of our records indicate that both driods presented authorization certificates signed by Lord Vader’s certificate authority. As you know, this CA has been the source of some dispute over time, but the finding presented is, again, simply wrong.

Finding 8.3: “Legacy intruder-tracking system inadequately concealed.” Again, this claim simply has no basis in fact. The intruder-tracking system worked perfectly, allowing the Imperial Fleet to track the freighter to Yavin. In analyzing the video, we expect that General Orgena’s intuition was “Force”-aided.

In summary, there are a few minor issues identified which require attention. However, the bulk of the report presents mis-understandings, unreasonable expectations, and focuses heavily on a set of assumptions that just don’t bear up to scrutiny. We are in effective compliance with PCI-DSS, this test did not reveal a single credit card number, and the deal with the Trade Federation should not be impeded.

Via Bruce Schneier.