Archive for the ‘AppSec’ Category

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.

I’m in violent agreement with anybody such as these researchers who contend that C needs to go. However, I really question the idea of trying ONCE AGAIN to replace C with an hitherto unknown or unused langauge. How many times do we need to try this before folks in academia clue in that it won’t work? Listen – if C++, Java, C#, Objective-C, C-, J++ or any of the other millions of other languages derived from C haven’t replaced it, why do we think “Ivy” will just brecause a few researchers at Berkeley say it’s all the rage? And for those sticklers who say Java isn’t derived from C: in questioning your assumption, I ask you to take a good hard look first at Java loops, arithmetic operators, and keywords; then compare those same artifacts to their cognates in a clearly non-C inspired language like Fortran.

Anyway, I’m not getting on the “new language” boat. Nope – not anymore.

A vulnerable browser, an exposure with no patch, a catastrophe for FireFox? And this is a surprise? Hey, since when did any of us believe security by obscurity is a good thing?

What do attackers tend to target? The most “props” (or financially) worthy ’sploits. Think FireFox or Mac OS X are secure? Think again.

Sorry to beat a drum here – but weaving security into the SDLC, understanding the requirements, use cases, production environment, and checking for potential defects early in (and throughout) the process, is the only way we’re going to get a real handle on software faults and subsequently application failures. For anyone who thinks using a marginally adopted application or OS, one that wasn’t designed by the “machine” over in Seattle, is going to get us all a free pass to the land of security. Think again.

This is about thinking about security from the ground up – it’s not about blindly accepting any thing, or application, without question.

A freeware C code analyzer; software security is all the rage right now, and this project seems like a particularly interesting one. I’ll watch this project alertly for further developments and maybe do some preliminary testing with it once I get some free time. C Code Analyzer