By now, everyone has heard of the Mandiant report. Many of you have taken the time to read it. This report and the discussion it generated refers to ‘threat’ so frequently that it’s worth discussing how its use of the word differs from what you commonly see here.
Posted in Software Architecture and Design | Comments Off on Threats threatening with threats
As we’re prone to say, “much ink has been spilt over the release of password digests” from LinkedIn and others. I’m, as is typical, profoundly disappointed in that amount of misinformation I’ve heard in security folks’ commentary on the problem and the underlying workings of digests, HMACs, and so forth. This blog entry represents a roll-up of a great discussion we had internally on our Software Security Group mailing list.
A Few Caveats
Posted in Software Architecture and Design | Comments Off on Securing password digests -or- How to protect lonely unemployed radio listeners
We have always done architecture work. In the past clients replaced their legacy systems with ‘new-fangled’ JavaEE. As they explored platform features, an ecosystem of web frameworks, and related commercial products (Netegrity’s SiteMinder). Realizing they needed help, they looked to us for:
Posted in Software Architecture and Design | Comments Off on Caching security architecture knowledge with design patterns
I’m at the BSIMM3 Conference, in an open source breakout session. The context: you’re an organization with a reasonable application security program. The question, “How to apply that same process maturity to open source where no ‘throat to choke’ exists?” Your organization and its software-providing vendors may not be perfect but at least you can choke someone if vulnerability exists. If you believe in the value of Software Security Framework (SSF) activities for built and purchased software, you understand that assurance activities (source code review or penetration testing) may apply to open source, but applying others (such as training, or SDL gating/exceptions, and so forth) might be as impossible shooting ghosts. So, we have a control problem:
We can’t tackle the “process improvement” problem with our open source providers like we can with those who build our software in-house, or those vendors from whom we acquire code.
Understanding, based on this, we lack as many ‘knobs and dials’ for improving the cleanliness of the pipes through which open source software flows… we may have a flow rate problem as well. Though I lack hard evidence, I’d bet this represents a proverbial iceberg’s tip:
An organization may deploy as much or more open source code as their own in-house developed code.
It’s interesting to think about the money organizations spend to secure the code they build vs. the amount of open source they consume in this light… (participants indicated they didn’t track this spend separate from their development efforts).
Posted in General, Maturity Model (BSIMM), Open Source Security, Web Application Security | Comments Off on Open source and software maturity models
Out at AppSec USA, the OWASP board met and decided that it was valuable to support a partnership model with private industry. The aim: figure out a way to allow private (or federal) organizations to shape existing OWASP assets to better meet their needs. Better meeting an organization’s needs will likely involve:
Posted in Security Standards and Compliance | Comments Off on An OWASP interaction model
A few posts back, we begun a series on Threat Modeling. As we begun writing the second installment in this series, it occurred to me that I’m using a lot of threat modeling vocabulary. When I speak on threat modeling I always warn my audience that ambiguity exists in some of the (even fundamental or common) terms used here.
Posted in Software Architecture and Design | Comments Off on What is threat modeling? A vocabulary of threat model terms.
We’ve probably all experienced organizations that rely principally on a single assessment technique (whether it be static analysis or dynamic analysis, manual or tool-based). Unfortunately, this is all too common for security practices. When this topic came up recently with the question (paraphrased), “Are there numbers that demonstrate the value of a security program making use of static, dynamic, and manual assessment techniques?” I thought some of our experience might apply.
Posted in Static Analysis (SAST), Web Application Security | Comments Off on When all you have is a hammer
Sometimes, people talk loosely about an important difference between static analysis and dynamic analysis. Static analyzers, they say, achieve 100% coverage. They may complain that dynamic tools struggle to get even double-digit statement coverage of an application under test.
Posted in Static Analysis (SAST), Web Application Security | Comments Off on Increasing static visibility
Ben Worthen broke the BSIMM story on wsj.com as was posted earlier.
Posted in General, Maturity Model (BSIMM), Security Standards and Compliance | Comments Off on Improving software security (maturity models and their ilk?)
James McGovern recently wrote a post on Gartner’s static analysis (SA) report. Among other things, he lamented the lack of actionable guidance within the report. A lack of implementation guidance doesn’t shock me from Gartner, I can’t say I expect that from them.
Posted in Static Analysis (SAST) | Comments Off on Gartner and static analysis