I’ve been seeing quite a bit of reading material hit the wire recently having to do with the topic of software (application) security.  The second folks I referenced there, the Denim Group (cool name, btw), seem to think that it might be starting to take off… they prophesy that it could actually get enough attention in 2011 that it could drive up salaries.  That’d be nice, but I’m not sure I’d go that far… at least not in absence of any concrete evidence (in other words, I’ll believe it when I see it).

Image Source: willscullypower.wordpress.com

But there’s also a trend that I’ve been noticing as well – which is folks tending to lump together functional and security testing under the same bucket.  As a dude who’s into efficiency, I would love it if that were the case.  I’d be all over it if we could use one set of tests for both security and functional testing.  However, I don’t think we can for reasons that I’m about to go into.

Now, please be advised that this is only my humble opinion. You’d be hard pressed to prove what I’m about to say.  But this is where the analysis has led me:

• Premise #1: Security testing (maybe/probably/could be) involves testing all execution pathways. So, my first line of thought here is that I think that determining if there is a security vulnerability in a given line of code is a hard problem.  A problem that requires evaluation of all execution pathways [ ?(n) where n is the number of pathways ].  My thinking here is that it has almost identical complexity characteristics as the halting problem.  Again, intuiting it and proving it are two very different things, so careful you don’t bite into this one too hard.
• Premise #2: Execution pathways increase exponentially according to lines of code. You’d think this would be a no-brainer, but there’s debate. However, it is clear from what we can tell that execution pathways grow – quickly – according to some rate that corresponds in some way (that looks at the early part of the curve like it might be exponential) with the number of lines of code, or classes, or modules, or function points, or whatever else you want to call them.  So I’m going to say “good enough for government work” on this one too.

So assuming both of these things are true, you have a vast number of execution pathways that you’d have to test if you wanted to do a black-box security analysis.  This is borne-out, at least partially and across a pretty small data set, by techniques like fuzzing.  What do I mean by that?  I mean, that you can observe that different inputs react differently in given execution pathways (premise #1) when you are conducting black-box test of software using a fuzzing tool.

Of course, functional testing doesn’t do that – or need to.  For example, there’s no need in a functional test to test every given input to a particular function.  Why would you?  You’d just test the ones you know you need to process to make the thing work.

Anyway, feel free to disagree.

Note:  this post was pre-authored and scheduled.  Apologies for any comments that are not immediately moderated.

Developers make mistakes.  I can say this with impunity having earned my keep as a software developer for quite a few years back in the day…  Anyway, the point is that it’s not a dig on developers when you say that they’re not perfect.

The actual numbers fluctuate a bit, but a safe assumption – one that errs on the side of fewer bugs rather than more – is around 10 bugs per thousands lines… or about 1% of code written by the average dev team.  We rely on the cycle of testing that occurs between the developer and the end user to catch defects – both security defects as well as others.  But as we know – functional testing is less useful for catching security issues than dedicated security testing.  (The “why” of that is an interesting topic – and one that I’ll probably go into again in a future post – but not strictly germane to my point here.)

Anyway, my point is that we’re seeing, quite naturally assuming the defect rates, all kinds of development-related issues in consumer-focused appliances recently: internet TV’s, game platforms, phones, etc.  It seems like the firmware of these devices is particularly vulnerable to attack; which is not surprising considering how vulnerable we all know the OS and (non-firmware) application space is.   So it makes sense that gadgets and home appliances would be vulnerable to attack just like their non-firmware counterparts.

But it begs the question about the firmware on non-gadget devices – platforms like medical devices, SCADA systems, cars, planes, etc.  Let’s call them “critical devices” – because security vulnerabilities on these devices can quite literally lead to loss of life under certain conditions. Is it the case that there are fewer issues on these platforms, or is it just that there are fewer people with the tools/time/ability to look at other platforms to the same degree as gadgets?

Let’s look at all the possibilities of what could be going on:

• Possibility 1:   software development is less error-prone when it comes to critical device firmware, leading to fewer defects.  In other words, developers make fewer mistakes with critical devices.
• Possibility 2:  software testing is more comprehensive when it comes to critical device firmware.  In other words, developers of these tools implement more rigorous safety procedures and testing, leading to fewer exploitable bugs.
• Possibility 3:  lack of marketplace availability stifles vulnerability research.  The devices are less available to the public at large, meaning that the majority of bugs are undiscovered and therefore still exploitable – but hidden.

Personally, I’m cynical enough to put my money on #3…  Maybe you believe some combination of #1 and #2 with a little hint of #3.  Either way, there are a number of consequences for the critical device and their firmware… it means, the most probable case is that there are bugs – out there in the wild waiting to be found – that potentially have life or death consequences in this critical code.

Not to FUD anybody out, but that seems scary to me.

Gary McGraw and the Building Security in Measurement Model (BSIMM) team just released BSIMM2 today. If you haven’t heard of BSIMM before, please take a look at the article I wrote about it over at eSecurity Planet. An excerpt is below.

“You are not a special snowflake.”

This is how Dr. Gary McGraw, author of Software Security: Building Security In, Exploiting Online Games: Cheating Massively Distributed Systems, and CTO of the software security company Cigital distills the findings from his Building Security In Maturity Model (BSIMM) and recently launched BSIMM2 projects. Quick translation: the measurement of whether or not the software meets quantifiable security levels is applicable to all software, regardless of what unique vertical, industry, or purpose it was written for. Although each firm’s process is unique, the measurement of a software security initiative is not.

Measurements are what we use to determine how well we’re doing and gauge improvement (or decline) over time. Measurements are particularly helpful when assessing the relative effectiveness of different methods.

For the rest of the article, please click over here.

If you’re wondering whether to use white box/black box/grey box testing on your applications – I recently wrote an article on the subject. Jay Leek, who heads up corporate IT security services for mobile technology company Nokia Corp, was interviewed for the article and had a lot of valuable, real-world insights to add.

For comprehensive application security analysis, “you need a people element if you don’t have it in your own team — look to an external provider for those services.”

Building security into the software development lifecycle is one of my primary research areas – and recently TechTarget asked me to do a video and podcast on the topic. They’ve been syndicated for viewing/listening through BusinessWeek and other outlets. If you’re interested in this topic, please check out the links below.

Countdown: Selling Security in the SDLC – Podcast

Building security into the software development lifecycle takes more than just a plan. You’re going to need the support and involvement of both the development and security/audit organizations in order to make it work, and that will take some effort. This podcast, featuring security expert Diana Kelley, will help you develop a plan for selling the value of security to all of the constituencies who matter in your organization, from the executive suite down to the developers and testers.

Software Reliability: Building Security In – Video

Fixing software security vulnerabilities during development is expensive, difficult and time-consuming. But fixing them after deployment is far more expensive and counterproductive. In this video featuring security expert Diana Kelley, learn state-of-the-art techniques for building a secure software development process.

There was an article that came around today called Software insecurity: Plenty of blame to go around over at GCN. The article contends that the blame for bad software lies at the feet of either developers or users, but that specifically who is to blame is up in the air. There is, of course, no shortage of opinion; check it out:

Stuart Katzke of the National Institute of Standards and Technology said that standards and guidelines developed by NIST could help… He said the suite of documents produced for the Federal Information Security Management Act effectively establish a level of due diligence for government IT systems.

Keith Beatty of Science Applications International Corp. went out on a limb by praising the oft-criticized Common Criteria program operated by NIST and the National Security Agency.

Do folks really need me to flay this or is the lack of useful dialog already self-evident? Look, Common Criteria certification is not the answer to buggy software. Microsoft’s products are common-criteria certified, and they still have plenty of bugs – if that were the answer, I think we would have seen less bugs as more software went through the process as opposed to more. As to the 150-page NIST document – I don’t see the connection; sure, it’s good to have an assessment program (special pub 800-53), it’s good to have checklists for developers (special pub 800-53), and so on. But is more documentation from NIST really what the industry has been missing in order to write bug-free code? I’m thinking probably not.

Of course, there were some more helpful suggestions:

Eset LLC … blamed the problem of buggy software on a disconnect between developers and users. What seems proper and intuitive to a developer often is ignored by users, who do strange and terrible things with their applications.

Although clearly this doesn’t address all the problems: bugs can occur even in the default configuration of products. If the Eset assertion were correct, shouldn’t the default configuration be bug-free?

Eric Cole of Lockheed Martin Corp. acknowledged that software often has flaws…

At last, an assertion I can agree with. All software has flaws; I’ll buy that for a dollar.

Is it just me or does anyone else feel like we’re trapped in a skit from “Mondo Bizarro”? Everyone is in a hubub about who to sue for software bugs: Howard Schmidt says sue the developers, Bruce Schneier says sue the vendors, and Pete Lindstrom says not to sue anybody, but to send vulnerability researchers to jail. It’s a veritable “who’s who” of information security, and they’re all saying the answer to software security is in the courtroom.

I, for one, wholeheartedly object to the trend. As a former developer, and a former vulnerability researcher, I can’t even believe we’re discussing the matter.

First and foremost, let’s get prison terms and chain-gangs off the table. Now, to be fair to Pete, he says in his blog that he was kidding about actually making bug research a crime, but the part about it being good-natured tomfoolery was in his blog – not in the published article. Some folks might read the article and not know that he was kidding – they might seriously consider his recommendation that bug research be “off limits”. And why not? Isn’t telling people about breaking copy protection illegal nowadays? Why not telling people how to “circumvent protection mechanisms” in software?

As to who to sue, clearly it’s not (as Howard Schmidt argues) the developers. I can honestly say that I would never have written a lick of software if I knew that I could be held personally liable for bugs. After all, all the developers I’ve ever met don’t get to control their own sechedule – they are told the deadline they have to meet (which is always too short) and they have to choose what corners to cut to make the timeframe happen. Not to mention the fact that no matter how careful you are, some bugs always happen. I don’t think I know anybody who would write software – or scripts, or batch files, or web pages, or flash, or word documents with macros in it, or anything else that could potentially be considered “code” – if a bug means they (and not the company) would be held liable. Oh, and don’t forget microcode – so no fancy new video card for you. I don’t think anyone would be left in the business to turn it into anything more than a lump of silicon and plastic – between microcode, ASIC’s, and drivers – there’s just too much software (shudder) to take the risk.

I also don’t think that we want to go with the Bruce approach. We already have a model for how this would go down – malpractice (and malpracitce insurance) in the medical industry (which, may I remind you, isn’t working so well nowadays.) Of all the proposals, his is the most innocuous – at least if companies are liable some people would still be around to write some software. Although, they would all be working for companies that could afford the “bug insurance” – like Microsoft, Oracle and Sun. Smaller companies would likely find that the costs were too high. Forget small companies giving away free software – companies that give away free tools like Counterpane’s PasswordSafe or Tenable’s Nessus would likely not take out an expensive liability policy when there’s no commercial upside other than marketing.

I don’t want to live in that world.

I came across the article, The truth about security this morning. I followed the link expecting (based on the title and the opening paragraph) to get “fired up” about yet another yahoo telling me how to do my job. However, I was completely wrong about this one. This a lucid and balanced look at disclosure, vendor responsibility, and legislation of software security. Two thumbs up on being fair – no thumbs up on suggested alternatives to the current process though.

You’ve probably already heard my rant about the Amir Herzberg “Unprotected Login Hall of Shame”. However, in the interests of getting my due props, I would like to point out the recent statistics by NetCraft citing that SSL use on back logon forms is on the decrease.

For those of you that missed my ramblings on this, here’s a quick ramp-up: the “Unprotected Login Hall of Shame” is a list of sites that don’t use SSL on the logon form – not the logon submission mind you – just the form. Apparently, many banks are in the “this isn’t a problem” foxhole right next to yours truly.

Some really good research on heap overflows in Windows. Useful reading material – this paper is short and to the point.