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.

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!

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.

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

• 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!

Sounds like QA right? Well, it should. Rest assured, there will be techniques, tools, and knowledge required to make the above statement true that even great QA people, process, and tools won’t be able to accomplish without some help from Security. Can QA get to 80% on their own? I don’t think so. Can they make more than 20% progress? I think so. My intuition is that QA folk with good tooling and a small amount of training will be able to specify and implement about half of what I call both a good test suite and good security tests.

In my experience companies don’t do security testing. Some of the more advanced companies with respect to Software Security have it on their ‘08 and ‘09 roadmaps. Product companies are more likely to have integrated security testing practices because of their comparatively tester-centric culture and SDL (vs. IT shops).

What are you seeing out there?

Technorati Tags: software testing

I don’t know when we’ll see such market forces affecting companies but do agree they would have a positive impact. Certainly, I get why the security space hasn’t been subject to market forces yet though:

• People haven’t historically been ready to pay for it
• Companies haven’t entered the market with something valuable enough to invest in

First: what people are willing to pay for. Simple question: if a development team has a $10M budget, how much does it, say, spend on quality? 10-40%? OK. How much does it spend on software security?

Second: The security space, at least with respect to Software or Application Security, has indeed moved beyond its purely missionary roots: people know they face a problem. People do not, however, know what to do about it.

Lack of direction hasn’t resulted from the vendors’ failed productization of a tool set or services though. No, it’s resulted from the lack of mature solutions in the space. Penetration testing companies were gobbled up last year but my experience has been that, for the most part, customers haven’t been willing to invest in these tools far beyond their initial purchases and the smallest amount of shepherding.

In fact, most organizations I’m working with have seen either a reduction in reliance on or an outright backlash towards penetration testing. Use of static analysis tools and code review, while on the rise, has not reached ubiquity in response (We’ve yet to see what will happen in a broader context, having only completed what I consider to be the early-adopter phase).

What do we do about it? Partnering more closely with customers has been something I’ve felt very strongly about. Listening more closely to them remains crucial. Even involvement at this level can be tricky to fund at all but the most interested customers.

There’s work to do as vendors too. Because, while we’re through the missionary phase, we’re not through the education phase in security. We must spend more time helping clients understand what attainable next steps look like for them. Moreover, I think we have to work with them to solve some of the problems we’ve avoided: we need to clarify salient next steps ;-)

How are we really going to get enough security knowledge in the hands of developers to change their behavior in a sustainable way? How are we going to scale code analysis so that it has some of depth of expertise, manually applied, but all of the consistency and speed of automation?

Technorati Tags: software security

With respect to security professionals, unfortunately, TJX now appears to be “the one that got away.” Let me explain, with tongue planted firmly in cheek.

If you’re in the business of providing discount items and the economy is a little weak, then business will be good. Apparently, it won’t matter that you’ve had a mishap or two with the data entrusted to you. It has always been my contention that only a small minority of people really understand the impact of stolen personal data and, even amongst most the people who do “get it,” the theft of nearly 100 million records of personal data is almost meaningless in its enormity. The victims are worried only about one record — theirs. Either it got stolen or it didn’t. And, if it did, it’ll get abused or it won’t. And, if it does, there is an ingrained belief the credit card company will “take care of it.”

Besides, there’s a huge sale and my niece needs galoshes — the green ones that look like frogs.

Yes, I believe that, as a rule, people care about the persona of the organizations they patronize. On the other hand, I believe we are at a point where the idea that “Stuff happens” because “Hackers did it” has seeped into the public consciousness much more deeply than “It’s the big, bad conglomerate’s fault.”

Virtually everyone can feel outrage at accounting scandals and multi-million dollar salaries and insider trading and so on, especially when you’re clipping coupons to make ends meet. On the other hand, virtually everyone had been impacted by “hackers.” Phishing, spyware, malware, malicious web sites, Internet scams, spam, MySpace worms, fake wireless hotspots, lions, tigers, bears — everyone has felt the sting of “the bad guy.” I claim that for Mr. and Mrs. Average American, it’s almost natural to feel a little sorry for TJX, to feel a camaraderie even, like “Hey, welcome to the club.”

Sure, we all believe they should have done more. On the other hand, I shouldn’t have clicked on that email attachment last year. I’m quite happy with my physical attributes, but it really sounded like a good deal. And that Nigerian gentleman sounded so sincere. And who doesn’t want a few new MySpace friends. We all make mistakes, right?

But what about those of us in the consulting business who have to convince organizations to put their trust in us. They have to believe us when we say that not spending on {data|information|application|software|IT} security can have intolerable business consequences. TJX would’ve made such a great example of just what intolerable really means — a veritable poster child for “See! I wasn’t kidding!” And now it’s ruined.

Okay, I don’t really want their stock to tank and have thousands more people affected. On the other hand, the least TJX could’ve done was fire a wing of executives so they could serve the consulting industry as an example in endless PowerPoint presentations for decades to come. (I still occasionally see technology demos that claim things such as, “And this could’ve even stopped the Morris worm.”) Now, we’ll have to go out of our way to omit TJX. We can’t bring up an example where nothing that bad really happened — for the organization, not the people affected by the thieves, of course. Now, instead of answering the question “How do we prevent this happening to us?”, consultants will have to answer the question “How do they get out of it so easily?”

Yeah, I’m sure it was rough in their executive suites for a while, but I’ll bet everyone is breathing easier now, walking around saying, “Woo-Hoo, we didn’t pull a CardSystems!” TJX has a very respectable 5-year stock climb, including three splits, and the current trade price is solid. Would they prefer to have invested a little more in IT security? Of course. Would they prefer not have unplanned millions in expenses? Of course. Do huge, unplanned expenses happen to large companies with some regularity? Of course. This one is special to us because we have some insight into how relatively easily it could have been avoided or detected, but for many, it really is business as usual.

Some pointers:

From Slashdot
Posted by: kdawson, on 2008-01-09 01:20:00

Stony Stevenson alerts us to a US Department of Homeland Security program in which subcontractors have been examining FOSS source code for security vulnerabilities. InformationWeek.com takes a glass-half-empty approach to reporting the story, saying that for FOSS code [1]on average 1 line in 1000 contains a security bug. From the article: ‘A total of 7,826 open source project defects have been fixed through the Homeland Security review, or one every two hours since it was launched in 2006…’ ZDNet Australia prefers to emphasize those FOSS projects that [2]fixed every reported bug, thus achieving a clean bill of health according to DHS. These include PHP, Perl, Python, Postfix, and Samba.

Firstly, I am a big fan of code scanning and believe that use of static analysis tools should always be one of the basic security steps integrated into every SDLC. However, there are huge problems with declaring security after passing a code scan with an arbitrary tool and a random set of rules. The most obvious issue is that security defects come in two flavors—bugs and flaws—each accounting for roughly 50% of defects in practice. Code scanning tools can only find bugs. Here are two stupid examples for effect: can a code scanning tool determine that no user authentication was performed? How about whether or not a playback attack will work?

The second most obvious problem is that the list of rules enforced by a static analysis engine can never be complete. Discussion about this is left as an exercise for the reader.

Architectural risk analysis (crazily called “threat modeling” by Microsofties) is, like code scanning, an essential software security best practice. Formal methods are one way to go about attacking the flaw problem. In the US we rely on flakier heuristic-based approaches such as the one we use at Cigital. But no matter the approach, we can’t ignore the architecture.

References

1. http://www.informationweek.com/story/showArticle.jhtml?articleID=205600229&cid=RSSfeed_IWK_All
2. http://www.zdnet.com.au/news/security/soa/11-open-source-projects-pass-security-health-check/0,130061744,339284949,00.htm

As many of you know, I have a podcast called “The Silver Bullet Security Podcast with Gary McGraw.” The premise of the podcast is to interview various security gurus, both from industry and academia. We’ve done some great ones, including Ross Anderson, Bruce Schneier, and John Stewart.

For episode 21 of the podcast, I interviewed the Cigital principals…the very people who (supposedly) produce this blog. You can download the podcast here.

We’ve also made a transcript of the show available in pdf form.

During the show we talk plenty about some of the lessons we’ve learned about enterprise software security from our work with customers. We also compare and contrast the Touchpoints, CLASP, and Microsoft’s SDL.

While you’re surfing for multi-media, you might get a kick out of this Merry New Year message from Silver Bullet.