Designing Secure Software

• Google security methodology compendium
• Threat modeling
• Are attacks the only threat?
• Why is threat modeling ignored?
• Miscellaneous
• e16n next Stage 4

Google is sharing a lot of their impressive security methodology in a recent collection of articles: How Google Does It: An inside look at cybersecurity. Of special interest to me: Threat modeling, from basics to AI.

• On “the end of security bugs”
• STRIPPED
• Incident response threat modeling?
• Using CSS and PDF as emulators running code

Claude Code Security has people predicting the end of security bugs as we know them I can’t imagine anything in the forseeable future doing that because all software has bugs, and vulnerabilities are by definition a subset of all the bugs (in a properly designed system). Bug-free code seems computationally infeasible for large systems, if only for the amount of testing required to confirm there are no bugs. What am I missing, or is it AI hype?

• on “Bitlocker, the FBI, and Risk”
• threat models to address hacklore
• software bloat
• software update release quality

How much AI use is acceptable for writing? It’s a hard question because it depends greatly on context, the reader’s expectations, and the fact that it’s difficult to usefully measure “how much”. How we address this matters for several reasons, including but not limited to: creator’s responsibility and originality, honest disclosure about research effort and sources, respecting the broad spectrum of opinion about ethical use of AI.

Writing in response to Adam Shostack’s excellent post “Bitlocker, the FBI, and Risk”. He nicely highlights the fundamental risk trade-off in data protection, and so long as we (often very rightly) prioritize availability we need measures that may compromise confidentiality. Also I especially liked the touch of a risk analysis not using numbers and explicitly pointing that out.

Dusting off this venue for writing at the suggestion of a friend in the interest of more discussion online because it’s “better if we move commentary off social media.”

Threat modeling is the most powerful, underutilized, easy-to-do security methodology we have: why isn’t everybody doing it already, or why do those who are keep their work secret? If you already threat model your digital systems and products, and are doing the work already then you are doing security right so you should share it with pride. Publishing threat models may be the best evidence of excellent security work that customers and users can appreciate the value of, short of a rigorous detailed design and code review. You’ve already done the work — or if not you really should — and making it public not only is great promotion but it also helps all stakeholders understand their respective roles and responsibilities in securing larger systems. (about 4600 words)

Demand more

I applaud CISA leadership speaking out aggressively at the mWISE Conference 2024 about the dismal state of software security (based on reporting in The Register, but it would be nice for www.cisa.gov to publish transcripts in order to ensure we are interpreting remarks with full context, given that the videos are paywalled).

(2300 words) Threat modeling isn’t just for software security; you can even threat model threat modeling. When a major software incident occurs, the first thing we should be asking is “show us the threat model”.

[Read More]

In a debunking blog post, Crowdstrike finally starts to describe that content files are digitally signed for deployment. The initial report oddly referenced file timestamps instead of hashes to designate the bad and good versions of the infamous Channel File 291, but now we know these were signed.