- on “Bitlocker, the FBI, and Risk”
- threat models to address hacklore
- software bloat
- software update release quality
See latest writings about software security and a little miscellania.
Kohnfelder, Loren. Designing Secure Software: A Guide for Developers. No Starch Press, 2021.
Designing Secure Software consolidates more than twenty years of experience into a concise, elegant guide to improving the security of technology products. Written for a wide range of software professionals, it emphasizes building security into software design early and involving the entire team in the process.
The book begins with a discussion of core concepts, covering trust, threats, mitigation, secure design patterns, and cryptography. The second part, perhaps this book’s most unique and important contribution to the field, covers the process of designing and reviewing a software design with security considerations in mind. The final section details the most common coding flaws that create vulnerabilities, making copious use of code snippets written in C and Python to illustrate implementation vulnerabilities.
You’ll learn how to:
- Identify important assets, the attack surface, and the trust boundaries in a system
- Evaluate the effectiveness of various threat mitigation candidates
- Work with well-known mitigations and secure design patterns
- Understand and prevent vulnerabilities like XSS and CSRF, memory flaws, and more
- Use security testing to proactively identify vulnerabilities introduced into code
- Review a software design for security flaws effectively and without judgment
“The writing in this book is very clear and easy reading, and the examples used are both captivating and easy to understand. Kohnfelder does a great job of making a point that is easy to understand, and most of the chapters could stand alone for developers just working in that one particular area.” (read the full review)
Transparent AI use
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.
[Read More]Risk Perspective
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.
[Read More]Dusting off
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.”
[Read More]Flaunt your Threat Models!
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)
[Read More]Demand more
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).
[Read More]Threat Modeling threat modeling
(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]
Crowdstrike further revelations
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.
[Read More]Crowdstrike External Technical Root Cause Analysis
The Crowdstrike July incident root cause analysis report provides new detail and requires reading between the lines to interpret (I welcome corrections with references if I got it wrong).
[Read More]Why tamper LLMs with guardrails?
Say what you will about LLM technology, it’s remarkable that we can do computations on the scale of billions of parameters training on large chunks of humanity’s collective text and media at all — and then it’s remarkable how you can talk to “it” in everyday language and get any kind of recognizable response out of it all, often (but not always) a pretty good one, and this is all based on the simple but powerful “select the best next token” algorithm run in a loop. The concept would have made a terrific sci-fi series, and here we are with it working in our cloud at scale.
[Read More]