« Security > 140 Conversation with Brian Chess | Main | Security > 140 Conversation with Brian Chess Part 3 »

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451c75869e201543262f4c0970c

Listed below are links to weblogs that reference Security > 140 Conversation with Brian Chess Part 2:

Comments

Atdre

If you are looking at a brownfield app portfolio and it allows Web traffic from the Internet to an Directory service, Database, or other Web service via connection strings, whether in the code, a config, or even by client-side certificates. These are assets that can be documented. Once documented, follow the data flow further into your infrastructure until fully completed. Now you have an asset-model.

Using the asset-model, you can determine the list of software components that touch or are touched by this data flow. Too bad only one commercial static analysis tool can work on single components without a full build. Why is this?

OSINT combined with focused runtime analysis activities could demonstrate which platforms are included in the asset-model. For example, Apache headers along with forced browsing and information disclosures could tell you which versions of CakePHP and CodeIgniter are being used across this asset-model. In addition, it would also identify packages such as TinyMCE, WebCalendar, Drupal, Joomla, Mambo, MediaWiki, Serendipity, and the ever-so-troublesome Wordpress (note that these are just examples). Then you can start to build a threat-model around these assets. I suggest another look at the Microsoft Press book, Threat-Modeling, on how to prioritize issues using STRIDE. Chapter 7 discusses this from a security testing perspective and could probably use an update that includes secure code review and secure application development/deployment management.

I do like FTA/FMECA and evidence-based management, but I agree that risk-ranking apps and chewing through them is the wrong approach for everyone.

Questions for Brian:

Why do you suggest Standardization is good and Risk-Ranking is bad, but your products and services do not reflect this? Is this a new path that you are embarking on? Where are the Fortify products that help us accomplish these goals and to create new strategies like them?

Recently, I saw a webinar with Brian around a new product that you were working on. It seemed to cover configuration problems such as the ones I've described here, but the focus seemed to be on DMZs and public-facing Internet web apps. I forget the name of the product, in fact, I don't even think the product name was mentioned in the webinar. I'd love to hear more about it. Perhaps a case study is in order? Or you could talk about it here in a part 3?

The comments to this entry are closed.