[This a guest post by Cigital’s Troy Jones, written in reference to episode 25 of The Silver Bullet Security Podcast, an interview with Jon Swartz.]

Gary,

Listening to your podcast with Jon Swartz today, you briefly mentioned Ralph Nader a couple of times. You said almost in jest, that “… we need a Ralph Nader for Security.” This got me thinking about a recent brownbag you gave on Software Security, where you mentioned that clients have implied needs for security but may not explicitly state their needs. I think the concept of implied need for software security and what Nader did to impact auto safety are entirely related.

Back in the 60’s people expected that the cars they bought were “safe”. Safety was not a marketing angle used by the car companies, and people did not shop around for the safest cars, but no one would buy an “unsafe” car. They just trusted and expected that the big auto makers had already thought about safety and “built it in” because no reputable car manufacturer would sell an “unsafe” car, would they?

It was not until Ralph Nader wrote “Unsafe at any Speed” that people began to question the safety of the cars they bought. When it became apparent that Detroit was selling them unsafe cars, the public outcry (not the book itself) prompted congress to act to enable novel new safety standards like seatbelts, bumpers that actually worked, and eventually crumple zones and air bags. So, people had an implied need for auto safety, but did not express that need until they became educated to the fact that they were not safe. Then they expressed their newfound need for safety to the politicians and also voted with their pocket books, buying safer cars. When consumers were provided with valid safety evaluations, from Consumer Reports and the National Highway Traffic Safety Commission, they changed their buying habits. Auto manufacturers (eventually) changed their approach in response. After years of fighting increasingly stringent safety regulations, they now compete to be able to advertise that their minivan has the highest safety rating.

So, what does all this have to do with software security? One point is that “safe” is relative term. You are safe if you feel safe. It is hard or impossible to know if you are actually safe but it is easy to have your illusion of safety shattered by hard facts. Your average consumer today may be oblivious or vaguely concerned about software security, but they don’t have the information necessary to make discriminating choices about what software to use or buy and to stay away from. There is no Internet Highway Safety Commission and no ratings to refer to. Without this information, people are unable to express their implicit needs. They are driving metaphorical Corvairs and they don’t even know it.

Another point is that safety and security are both relative. The worst Yugoslavian POS manufactured today is probably much safer than any car rolling off the Detroit auto lines in 1965. It is conceivable that 50 years from now people will look back and wonder how we survived without collision avoiding auto-pilots in our cars! People’s expectations for “safety” evolve over time and hopefully their actual safety improves as cars are better engineered, but there is no endpoint- no “safety finish line”. I think this analogy applies to “Software Security”. Software should get more secure over time if security is considered an important goal, but software will never be 100% secure. Good for job security but bad for everyone who depends on software to work securely.

A third point is that the initial reaction to unsafe autos was to build safer highways. Wide-open, straight, and fast highways seemed to be more cost effective than engineering better automobiles. It was not until highway traffic deaths began to skyrocket that everyone realized how effective automobiles are at killing the occupants involved in an accident at 75 MPH with no seat belts. The same approach has been taken on the internet. Bigger pipes and better firewalls should take care of the problem. No need to design and build more secure software! But the common folk will eventually realize that building a super information highway to their most confidential data has lots of unintended negative consequences, especially when it is so easy for the crooks to get past the vigilant but not-too-bright night watchman.

The last point I would make is that it took a fairly long time and a number of contributing factors for something to be done about auto safety. While Nader’s book was certainly a catalyst, it was not the “Auto Safety Pearl Harbor”. He merely recognized and assembled the information in a concise format that allowed people to understand and take action against a problem that had been growing worse for a long time. My guess is that the same will be true for software security. There will not be a “Software Security Pearl Harbor”. But through your continued evangelizing, through books like Jon Swartz’s “Zero Day Threat” and by their own negative experiences, people will eventually realize that something has to change and will demand action from software vendors, perhaps increased regulation from Congress, and maybe even a rating system to identify the worst offenders and the most secure software available so that they can make better choices. I am convinced that attitudes will begin to change soon, as the current rate of increase in cyber-crime has us on a trajectory to reach 1% of total GDP with 4 years. If that happens, it will definitely get the attention of quite a few people and may drive the expression of latent needs for software security.

There are three new books (recently released) that are worth a look. Once is an absolute necessity for any security practitioner. The others may be interesting for some readers of the blog.

The book that you MUST READ RIGHT NOW is the second edition of Ross Anderson’s Security Engineering book. Ross did a complete pass on his classic tome and somehow made it even better. It also comes in handy as a weapon as it is so heavy. Books like Ross’s are a refreshing reality check from the usual pablum published in computer security.

Simply put, this is a must read book for every security professional. I don’t have my real copy yet from the publisher (but they say one is on the way), but I did take a close look through the manuscript. Ross retains his number one slot on my list of top 5 things every software security person should read.

Incidentally, I interviewed Ross for Silver Bullet last year (in April). Ross’s episode is the most popular of all 24 episodes released to date with over 18,000 downloads. You might want to give that a listen as well.

The other two books that are worth a look are Crimeware and The New School of Information Security. Lets cover them in reverse.

The New School of Information Security is a book worth buying for the cover alone. I know of no other computer security book with a Kandinski on the front. Even though I know Adam Shostack from way back (and never could have predicted that he would become a Microsoft guy), I saw his book at RSA, bought it for the cover, and only then discovered that he was the author! My plan was to give the book to a good friend who I know is a huge Kandinski fan. On the way to complete that errand, I had a chance to look though the book and now I need a copy of my own! If you’re a follower of the economics of security school (which Ross and Bruce Schneier have helped spearhead), you’ll like this book.

Crimeware is an academic tome written by my friend Markus Jakobsson. I contributed a chapter on software security bug taxonomy. My copy showed up last night, and I have earmarked more time to read it thoroughly. The enemy has changed over the last decade, and criminals are bringing the game to a new level.

Spring may not be the best reading time, but it does appear to be the best time for a crop of interesting new security books!

Some people start “Security Testing” by buying and using a pen-test tool on project. Such tools uncover security vulnerabilities (though they seldom help with root cause analysis or even obtaining double-digit code coverage).

These tools are degenerate, at best, in facilitating a security testing strategy. Why? Because, these tools are “black box” tools. What are black box tools?

The term “black box” stems from old testing literature and means “without internal knowledge”. An external perspective has always excluded “code” but sometimes goes as far as (in my opinion appropriately) software design. Obviously, you need to know something about the application’s architecture and design to test it though and the slope gets slippery.

In the realm of penetration testing, the term “black box” often has meaning beyond the tester’s knowledge of the product. OSSTM defines “black box” to mean that neither attacker nor defender are given knowledge of each other. They mean for this test procedure to accurately represent the kinds of opportunities, need for stealth, accessibility, and exploit that a real attacker would have, and also to evaluate the defender’s abilities to identify and prevent or recover from attack.

Because black box tools to a large extent run canned tests they will not satisfy my security testing goal (see previous entry) of having run tests that one traces back to requirements. ‘Requirements that one created as a result of doing risk analysis that determines exactly what behaviors (and their impacts) should be avoided were the software attacked.

Arguably, security folk have “cached” this risk analysis and these implicit requirements in the pen testing tool. Fine, this is that small benefit that I mentioned pen tests do provide. And, they DO find bugs. Again, this is at best a degenerate case of security testing in the same way running a fuzz testing tool is a degenerate way of conducting functional testing.

For QA folk wary of accepting the previous statement, it will suffice to say that you wouldn’t defend your job based on achieving less than fifty percent coverage would you?

Vendors have begun using hybrid approaches (this will only become more common). Do these approaches solve our coverage problem and allay our concerns?

I demo’d Compuware’s DevPartner, which has a poorly advertised (and perhaps now nacent) security scanning capability, a few years back and was pretty impressed with the start they had made in hybrid .NET analysis. I’m not sure where it’s gone since then. Fortify’s PTA also combines static and dynamic analyses to help prioritize static findings and provide root cause analysis for dynamic ones.

These hybrid tools don’t get our security testers off the hook either though, as they’re still not addressing the project-specific risk analysis nor are they anchoring tests in requirements.

This entry started as an email to a co-worker: Will. I’ve edited to make it a bit more readable, but in an attempt to blog more often and less formally, I’m only applying the thinnest editing veneer. We were discussing whether (again) moving entitlement/access control decisions out of the application code really made sense. Will was concerned about not making the developer responsible for implementing access control for an interface. I’m putting words in his mouth, but how can one “build in” security if the responsibility for one of the more fundamental security controls is taken away from the developer?

The notion of externalizing the access control is spot-on from a design standpoint. There are many reasons to externalize and one can argue that many of the problems with web application security is that the auth/auth got shoved into the application and the application developers were not qualified to write such code.

I think what was making Will nervous was the question of WHO makes the decisions when configuring this externalized mechanism. It’s also the case that WHEN do these configuration questions get handled. The answer to date is that there is some sys-admin or app-admin that does this after the application is deployed.

Historically, this hasn’t been done very well and/or the RBAC systems put in place to configure and manage such auth decisions have been notoriously difficult to administer at scale. I will, however, say that one of the arguments for externalizing the mechanism is that the job of implementing auth/auth requires more than the PDPs/PEPs in the app; it’s all of the additional software for managing/updating the PIPs where the bulk of the work resides in building a robust access control mechanism. Again, the app-dev guys aren’t the best person to write all of the management software and you wind up with the problem where administrative functions is just a series of configurations handled through a command shell or your favorite editor.

This still doesn’t properly answer the question of WHO. Admins don’t have the knowledge to properly configure and the developers don’t have a proper notion of who should be using the interfaces they create.

This is really an architects job, but while the architect has the breadth of knowledge to make the decision yo (trying out this new gender-neutral pronoun) lacks the tool to understand the actual interfaces that exist. The architect will have pre-defined about 80% of the actual interfaces, but the implementers will have created others to solve implementation level problems. So, 20% of the interfaces will be entitled without much thought.

So, let me make another point of externalizing the auth/auth mechanism. That is what we need here is a tool that can turn all of the code into (UML) descriptions of all the interfaces. We need to decorate that list with the entitlement data, but we can only do so if there is a canonical way for the tool to read the entitlement information about said interface. If we can do this, now we’re cooking with gas since we could then write some kNN-like algorithms to compare each interface with other interfaces like it so we could see where there are potential, logical inconsistencies.

Technorati Tags: access control, entitlements, design, architecture

I have been writing a monthly column on computer security and software security since October 2004. In the beginning, the column appeared in Network magazine. Later, that magazine was eaten by IT Architect. Here’s a set of pointers to those early articles:

• Who Should Do Security? (October 2004)
• Application Security Testing Tools: Worth the Money? (November 2004)
• How Do Real Bad Guys Break Software? (December 2004)
• Innovative Rootkits: The Ultimate Weapon? (January 2005)
• Are We In a Computer Security Renaissance? (February 2005)
• Where Does Trust Come From? (March 2005)
• Is Your Mac Really More Secure? (April 2005)
• How Does Security Fit With Engineering? (May 2005)
• Are Cell Phones the Next Target? (June 2005)
• Is Penetration Testing a Good Idea? (July 2005)
• Is VoIP Secure Enough For Prime Time? (August 2005)
• Is Cisco Naked? (September 2005)
• How Bad Is Intrusion Detection? (October 2005)
• Is Security Really About Getting Nothing Done? (November 2005)
• When Does Security Cross the Line? (December 2005)
• Is Sony BMG Run By Malicious Hackers? (January 2006)
• Is Application Security Training Worth the Money? (February 2006)
• How Flawed Is Microsoft? (March 2006)

We all know what’s happening to magazines and newspapers, though, don’t we–they’re turning to bits. When CMP killed IT Architect magazine (along with most of the rest of their paper publications), they repurposed much of the content into websites. I started writing for darkreading.com from the very beginning. Here’s a set of pointers to the darkreading articles:

• Microsoft’s Missed Opportunity (May 3, 2006)
• New Terrorist Profile: Phone Users (June 13, 2006)
• If You Build It, They’ll Crash It (July 7, 2006)
• Google is Evil (August 4, 2006)
• Keep Your Laws Off My Security (September 7, 2006)
• Diebold Disses Democracy (October 9, 2006)
• Boarding-Pass Brouhaha (November 2, 2006)
• Foxy Vista Henhouse (December 11, 2006)
• Hurray for Hollywood!? (January 12, 2007)
• Security’s Symbiosis (February 27, 2007)
• Compliance As Kick-Starter (March 12, 2007)
• Want Turns to Need (April 20, 2007)
• Certifiable (May 9, 2007)
• JSON, Ajax & Web 2.0 (June 7, 2007)
• Consolidate This (July 12, 2007)
• The Ultimate Insider (August 14, 2007)
• Mobile Insecurity (September 14, 2007)
• Online Games & the Law (October 11, 2007)
• Beyond the PCI Band-Aid (December 10, 2007)
• Software Security Strategies (January 9, 2008)
• The Truth Behind Code Analysis (February 13, 2008)

Just recently, I decided to move my monthly column to informIT. The readership is much larger, and I like the affiliation with the company who publishes my books. As part of that move, you can also expect to see Silver Bullet syndicated through informIT as well. You can help me make the move a success by keeping up with my column through informIT. (We’re also planning an RSS feed for articles too, so watch for that as well.)

The first column for informIT is just as much about business as it is about technology. One of the issues we constantly face at Cigital is the problem of helping our customers sell the idea of software security best practices up the chain. A common (and misguided) view is that software security best practices increase development time and add cost. As you can see in my first column, that’s simply not true. Here’s a pointer:

Software [In]security: Paying for Secure Software

I’m very much interested in your feedback on my column and any suggestions you have for topics. Feel free to use the forum below to get in touch. Thanks for reading!