let us close this looooong discussion and move it on, once we meet. Actually LinkedIn did not let me to accept your invitation - there seems to be a technical problem (I mainly manage my Facebook account but use LinkedIn as well).

Let me just comment on two or three points:

David’s statement: “Largely because of insecure design and implementation of whatever the firewall is trying to protect.” is not really accurate from my standpoint. It is one of the lines of defense and there is absolutely no reason why a computer should accept requests from the outside even though a service like SQL has to accept requests from wihtin the computer. Yes, I agree that in a perfect world everything would be perfect and SQL would not be attackable but the fact is, every service is from a certain point of view. Therefore we can switch the firewall off as soon as the criminals stop to attack systems.

Dre made a statement that the rating system should only be applied to software that makes it to full disclosure or bugtraq or CNN. Why? There is no reason for that. Just because these websites (and you may add a few others) does not mean that there are no exploitable vulnerabilities. Additionally, where do we see the biggest attack vector at the moment (beside social engineering)? Not the OS anymore but a lot of applications sitting on top of it. As I said (and still say): I am definitely not against certification but we really seem to have a major disagreement on how this should look like - which is really in the fundamentals on what it needs to have a secure product. To switch to the aircraft analogy: There are aircraft types - even though the have the certification to fly - I do not like to use if I can avoid it. Just because I do not trust the company or the processes behind it as far as I can judge. They do not even crash more than others. It is just my feeling.

With regards to licenses: No we do not have anything like that - not even in the professional business. I am a CISSP as well but I still would have the right to do my job if I would not have it. Do I do it better since the certification? I doubt. Did I learn something during the preparation? Sure!

I could not agree more that this model does not scale. Looking at the trade-off between limiting access for the sake of having only “competent” people on the web vs. freedom of speech the choice is already made and clear.

Yes, I am biased. And yes, I believe that the work we are doing within our company does not have to hide. It was not that way a few years ago. I know - and that is the reason, why I participated in this discussion - that there are absolutely great and competent security persons out there having a different view and different ideas. Engaging in an open and fact-based dialogue is the only way to move the industry. This is necessary and a lot of fun (even though my keyboard probably soon runs “out of letters” if we go on :-))

Drop me a mail and tell me where you are based. Might well be that I am in town once (especially if you are in EMEA) and the dinner would go on me (if you would join)

Roger

I don’t see it coming to that. I tried to address open-source issues in my Why pen-testing doesn’t matter post.

The interesting issue is that with my five-star rating system, I suggest testing the code. So at some point, some of the code (the sample) needs its source-code to be opened to at least the vendor-neutral verification organizations. However, some software vendors will instead choose to open-source those same samples to get public review, as well as the process review.

There is an interesting point to be made about security in closed-source software. Before you completely jump out of the debate, I’m curious as to what you think about stolen source-code? Is closed-source software really protected from external review, or is this security by obscurity?

We have similar things today in our Security Development Lifecycle, there are Threat Models, there is fuzzing, there is source code scanning etc.

Yes, but is there Continuous Integration, secure manual code review, secure design inspection (because threat-modeling is just secure design review), and continous-prevention development (i.e. advanced form of defect-driven development or regression testing)? If the SDL uses fuzzing and source-code scanning - are these CWE-Effective?

However, if a car has to comply with a crash certification, the manufacturer knows exactly how and where the opposite car will crash into my car. So I will make definitely sure that I will survive this standardized test but it might well be that the angle of the crashing car is changed by 10°, the car will fail. I can give you an example: Years ago cars were tested when they crash head-to-head, center-to-center. And there was a lot of improvement there. However, as soon as you do not hit center-to-center anymore but kind of just 50% of each car, the results were disastrous. Therefore they had to change the tests later on.

Yeah, I’m almost done with the car analogy. As Andy Steingruebl of SecurityRetentive said on the Geekonomics Blog, “Let’s be clear to distinguish between the different scenarios though. As has been repeatedly pointed out cars are designed to be “safe” under “ordinary” operating conditions. They are not designed to be “safe” from a malicious adversary. A car won’t stop someone from deliberately ramming you in the area of the car most likely to cause personal injury. It won’t be safe if someone cuts the brakes, loosens all the wheel nuts, etc. Heck, it won’t alert you to those situation either”.

I also think my notion of using code coverage deals with this problem well, and I do see future problems - but I expect that my concept of a five-star rating system based on code samples will be able to scale. See some of my posts on formal methods, of which I’ll be posting a great deal more on soon.

We (Microsoft) want to improve security – that is a clear commitment from us. So if we are coming to the five star rating system I agree that we have to test and certify the product.

Uh oh. Here it comes. I see where you’re going with this. Very clever!

However (to me even more important) I would want to make sure that there is a process where security is built into the product from ground up and where it is actually auditable what went on.

See, I don’t care about the method. Dan Bernstein writes secure code and I don’t care how he does it. He doesn’t need Six Sigma or any process or anything at all. DJB needs his brain and he delivers.

Commercially, this is what I would want to see.

People use more code than what is available commercially. Did you know that there are open-source alternatives to Adobe Reader, Microsoft Office, Internet Explorer, and even Apple QuickTime? Did you know that people use these?

The reason for that is in the nature of how threats change. Integer overflows where bugs a few years ago but nobody thought that they would ever be exploitable. Today they are.

Yes, the five-star rating system will need to be based on the percentage of CWE-free security-related bugs in the code. CWE will scale to these issues. Did you know that integer vulnerabilities affect Java, but they don’t affect C# .NET? Kudos to Microsoft for this, and it will be shown in MITRE’s CWE program.

If we are not doing defense in depth from the ground up, we will not improve security.

Yes, there is assurance and there is functionality. All defense in depth involves functionality. Just like we have interstate highways, seat-belts, and roll-cages - we have OS, network, and software defenses. This functionality must also be improved, but outside of assurance (or having its own separate assurance). Do you see how this is out-of-scope?

I think that initiatives like SAFECode - and there are others – are the way forward.

I will write about SAFECode at a later time.

Last but not least I would want to have a clear understanding if I buy something that there is an incident response capability with the company actually shipping the product. I would never ever buy a car without having a service contract and having a garage nearby being able to help with problems. So, certification/five star rating – fine with me but for the product, the development process, and the response process.

Roger, this is feature creepism at its best. You must work for Microsoft! I think that people can decide on their own who has the best reponse and support process independently from a five-star rating system focused on software security assurance.

I really had no idea from the start of our conversation that the two of us would be in almost violent disagreement about such basic issues. Please tell me you’re kidding? Good joke, right?!

Coming to the point I made about certifying a product in a single state. This is actually what we would do. Somebody would release a product and one single version of this product would be tested and certified. In the meantime there might have been bug fixes (and there will always be bugs in which product ever) and there will be security update (the same). What do we do with them as they change the product?

New ratings would be for specific versions at a specific patch level. Users will be welcome to look at the trends of products over time.

“Dre: I will do everything in my power to prevent this from becoming a commercial label.”

So how should that work in order to make it fair and scalable with all the millions of applications being released every year? You want to push that and make it a market enabler and I understand that and as I said, I am supportive with that if we cover everything. But it has to be scalable. We alone released more than 300 products last year – and this is without our partners. And nobody would want to wait for 6-8 months until somebody working in the spare time would do the review. If it is done by the government it might even take longer.

My suggested system shouldn’t provide ratings for all the million applications. It should provide ratings for software that make their way onto full-diclosure, bugtraq, and CNN. I know that Microsoft ships 300 products, but not all of them are critical path for software security assurance rating systems.

The problem that Microsoft presents is that you have so much code, that only samples are going to make their way into the rating process, and they should be based on your worst code in that product. To this - I say great. Microsoft has no idea what a mistake it is to provide an OS with the browser built-in from a security perspective. Unix had the concept of writing small programs. Small programs means small code. OS with browser and everything built-in means lots of code. How many millions of lines of code is Vista? Let’s sample and find the worst secure code in Vista and rate it based on that. Why? Because security vulnerabilities are a disease. If you have cancer in your body, you don’t say “well I have billions of cells, who cares about the few cancerous ones?”.

You know what? Mozilla and Apple have the same problems, so don’t worry too much about it. Worry about writing less code. Less code means less security problems. This is a concept that DJB understands, and he doesn’t need a process or response model to augment his incredible results.

On the other hand I saw too many consumers that switched off the firewall “to tune the machine”. Should we forbid that?

Yes, you should forbid that. If you can’t forbid that, then don’t include firewalls as a security feature in your products. Optional products should be available as third-party. Or sell a separate firewall product such as ISA Server Personal Edition or something. I understand that users want features bundled - but if it’s not helping then it’s hurting. Leave the insecure, unworkable features out. Make modern exploit countermeasures that do work a permanent, prominent feature.

Here’s a better example for the next operating system you release - don’t let users turn off ASLR. Keep it on, period.

Should we have a driver’s license for the Internet? This is actually a good discussion as security collides with the social requirement for “freedom of speech”. I cannot and do not want to give an answer.

We already do have driver’s licenses for the Internet. CCNA and MCSA are great examples of what companies look for when hiring system and network adminsitrators to enable and promote OS/app security functionality for their users. It’s called “IT Security” or “Information Security Management” and we have CSO’s, CISO’s, and all sorts of security people that have CISSP’s, CISA’s, and a million other programs.

Of course, these are more like “bus driver, taxi driver, or truck driver” licenses, but there is no way we can certify every user for computers in the way that we can certify drivers for vehicles today. We may never be able to do this because of the scale of features and security functionality in software - plus how often this all currently changes.

It’s up to IT and vendors to mature and provide checks against the users who are “riding in their well-built cars”. Are your kids wearing their seat-belts? Did that person just throw something dangerous onto the road out of the bus window? Is that criminal in hand-cuffs with a shield between backseat passengers and the police officer driving the vehicle?

We don’t have driver’s licenses for developers who write code securely for the Internet. I know that the SANS-SSI is going to screw up their program at some point (SANS always does), but what truly should happen is that Microsoft/MCP and Sun/Java developer certifications should include security in the basic certification processes, as well as provide an extended criteria certification program. These are the licenses we need right now.

Why should the security of an operating system depend on the intellectual strength of the user when the safety rating of a car is agnostic to whoever the driver might be? Because the consumer has a gazillion of not controllable option to mis-configure the Browser, the applications and the OS as everything is multi-purpose. This is the big, big difference between a car and software – and it is product agnostic.

Because applications usually have too many options, too many features, are built with too many components, and contain way too many lines of source-code.

When I look at the discussions we had on this blog, we should at some event in time actually run a podium’s discussion – would be pretty interesting

I added David Rice and you on LinkedIn. There was a similar dicussion at VERIFY Conference in Washington, DC at the beginning of last month. Joe Jarzombek started the discussion from the podium - and I suggested exactly this five-star rating system program based on samples of source code. A few others suggested “compliance”, “process improvements”, and “incident response improvements” in no particular order. Someone pretending to be Dan Geer and Adam Shostack also mentioned the problem with breaches and the lack of information sharing (although this was countered with the existence of information sharing alliances such as ISAC’s including FIRST and the Financial ISAC). Somebody else forgot to mention exploitation countermeasures and ISM functionality, as well as the basic Orange Book concepts, and another person forgot to mention formal methods as the future for software security assurance.

Roger said, “If I look at some of the proposed measures, from your point of view you can just achieve adequate security if the code is available – which most Open Source applications prove to be wrong.”

I agree. The “openness” of software has not proven itself to offer greater security. This does not mean I am against open source, simply that the numbers have not entirely supported the assertion that open-source is better than closed-source. Openness *can* help, but it is no guarantee. Have some open source companies exhibited the ability to address security better than other software manufacturers? Yes. Absolutely. But this is a company issue, not an open/close-source issue. There are hundreds of open source projects that have simply not responded adequately to consumer’s security needs. The desire, ability, and capability to address security needs are largely an economic issue that is company-specific; that is, do open source projects/companies have the resources and the incentives to adequately address security? The answer is not nearly as clear as open/closed-source evangelists would like us to believe.

Roger said as a response to my comments regarding “the nuts behind the keyboard,” “Well, this is a more than unfair accusation. Part of the reason why this blog comments are here is just me saying that this is unfair and I do not like it.”

Amen. The notion that users are “idiots” is prevalent within the IT industry in general and the IT security industry in particular. For instance, there are many terms used to refer to users. “ID10T”. Also, PEBCAK, Problem Exists Between Chair and Keyboard. And, of course, PICNIC, Problem in Chair, Not In Computer. And finally, UCOM, User Can’t Operate Machine.

But the notion extends beyond just the IT industry. In a recent article I believe in CSO magazine, bank executives were stating, anonymously of course, that “users are dumb” in regards to how and to what extent (i.e., not at all) users protect their computers from exploitation. This is an increasingly pervasive sentiment and a troubling one.

But the fact that user’s turn off firewalls is another red-herring. Why do they need firewalls in the first place? Largely because of insecure design and implementation of whatever the firewall is trying to protect. In general, firewalls as well as a majority of other similar security protections are a network response to a software engineering problem. These security protections do nothing to solve the problem why software is, and why it largely remains, vulnerable.

Roger also responded to my question about the security of a system relying on the intellectual strength of users, “Because the consumer has a gazillion of not controllable option to mis-configure the Browser, the applications and the OS as everything is multi-purpose. This is the big, big difference between a car and software – and it is product agnostic.”

This is where we disagree. To answer, let me do some set up. First, is software more complex than a vehicle? Yes. Undoubtedly. Second, based on this complexity, will users need to be better informed and educated to “drive” safely on the Internet? Sure, but the question that remains is just how much more must users learn to “drive” safely on the Internet?

The current answer, I believe, is: users must have an exceptional, even an extraordinary level of knowledge in order to protect themselves. They are in fact expected to think and act like the engineers who designed these systems. This is unrealistic. So, which of the following is least implausible? Expecting people in developing nations who, based on statistics are largely disadvantaged educationally, or, as Roger said, living in slums, must now become the equivalent of first-world security experts in order to protect their computers (which first-world computer users cannot seem to do either by the way)…OR…imposing some level of educational requirement (the equivalent of a cyber-driver’s license) to “drive” the global network no matter where you live? I certainly don’t have an answer.

The “let’s not hurt the already-disadvantaged” sentiment is laudable and I share Roger’s concern for the problems of developing nations. This is a hard problem.

That said, a product that is so complex that neither the manufacturer nor the consumer can apparently protect it sufficiently is troubling. To imply that “hey, that’s just the way we designed the OS (as multi-purpose) and the market has to live with that,” is unacceptable. It is also largely unprecedented (or has been corrected where there might be precedent). As a public policy issue it is down right dangerous.

When there are services/products that are beneficial to humanity, but pose substantial risk to society, such as zoos (risk: wild animals escaping their enclosures), nuclear reactors (risk: melt downs, transporting HAZMAT), and even toasters (risk: electrocution), the maker/provider has eventually become subject to strict product liability. That is, yes, these things are beneficial to society (as an operating system undoubtedly is) but the risk is so great should something go wrong that the individuals who choose to engage in making/producing this product must be held accountable for any foreseeable and unforeseeable circumstances. In the case were users are also culpable as well as the manufacturer, the user is liable under contributory negligence. Everyone shares the burden comisserate with their responsibility.

This is a public policy issue, and an important one. Presumably, a multi-purpose OS would run on just about anything; making the radius of risk should the OS have a defect/vulnerability quite extensive.

Strict product liability encourages manufacturers to build systems that are better focused for intent, better engineered for use, and better designed for safety/security. Users also share the burden under contributory negligence. This is not the current state in the software market. Users bear the entire burden should anything go wrong with their computer system, manufacturing defect or not.

So the biggest question of all is, is software so special that it should not abide by, or adhere to, good public policy?

I like Roger’s thoughts on getting together for a chat. Roger is a wonderful thinker and I welcome the opportunity.

I like the car analogy as it shows where the system proposed would have the challenges. Let’s take the car crash tests. I could not agree more that these crash tests highly improved the way cars are built and that they are much, much more secure. We have similar things today in our Security Development Lifecycle, there are Threat Models, there is fuzzing, there is source code scanning etc. However, if a car has to comply with a crash certification, the manufacturer knows exactly how and where the opposite car will crash into my car. So I will make definitely sure that I will survive this standardized test but it might well be that the angle of the crashing car is changed by 10°, the car will fail. I can give you an example: Years ago cars were tested when they crash head-to-head, center-to-center. And there was a lot of improvement there. However, as soon as you do not hit center-to-center anymore but kind of just 50% of each car, the results were disastrous. Therefore they had to change the tests later on.
So, let’s give the certification an additional thought:

We (Microsoft) want to improve security – that is a clear commitment from us. So if we are coming to the five start rating system I agree that we have to test and certify the product. However (to me even more important) I would want to make sure that there is a process where security is built into the product from ground up and where it is actually auditable what went on. Commercially, this is what I would want to see. The reason for that is in the nature of how threats change. Integer overflows where bugs a few years ago but nobody thought that they would ever be exploitable. Today they are. If we are not doing defense in depth from the ground up, we will not improve security. I think that initiatives like SAFECode - and there are others – are the way forward. Last but not least I would want to have a clear understanding if I buy something that there is an incident response capability with the company actually shipping the product. I would never ever buy a car without having a service contract and having a garage nearby being able to help with problems. So, certification/five star rating – fine with me but for the product, the development process, and the response process.

Coming to the point I made about certifying a product in a single state. This is actually what we would do. Somebody would release a product and one single version of this product would be tested and certified. In the meantime there might have been bug fixes (and there will always be bugs in which product ever) and there will be security update (the same). What do we do with them as they change the product? That has nothing to do with the “wearing seatbelt” analogy – even though it is a very good one I use often in presentations.

“Dre: I will do everything in my power to prevent this from becoming a commercial label.”

So how should that work in order to make it fair and scalable with all the millions of applications being released every year? You want to push that and make it a market enabler and I understand that and as I said, I am supportive with that if we cover everything. But it has to be scalable. We alone released more than 300 products last year – and this is without our partners. And nobody would want to wait for 6-8 months until somebody working in the spare time would do the review. If it is done by the government it might even take longer.

“Dre: Sure. Are they anything similar to the stuff I’m talking about? Am I totally off-base or living too far in the future?”

Well, the consequences are part of what we are discussing and this is one of the reasons, why I comment on it. I pretty rarely do it to that extent as there are too many blogs who just love to attack Microsoft. This was/is a fruitful discussion to me (even if I still push back on certain things).

The way I look at the current trend are probably more on a high-level view which then has to have an influence on tactical solutions like your suggestion to the “five-star”-rating system.

Now, let me change to some of David Rice’s comments, I would like to give some thoughts:

“In today’s software market, the same situation exists as it did in 1950s and 1960s America. Software consumers are “the nuts behind the keyboard,” the “idiots” as they are deemed. It is software consumers that are blamed extensively for not configuring their “vehicle” correctly. “

Well, this is a more than unfair accusation. Part of the reason why this blog comments are here is just me saying that this is unfair and I do not like it. However, it is a combination of better technology, user interface, and consumer knowledge. The ones that ever heard me speak publically about these things know that I always object statements like “consumers have to access risks” as they are not able to do it – today. On the other hand I saw too many consumers that switched off the firewall “to tune the machine”. Should we forbid that? Should we have a driver’s license for the Internet? This is actually a good discussion as security collides with the social requirement for “freedom of speech”. I cannot and do not want to give an answer. I am in Kenya at the moment and I will prepare a blog post on my impressions (on http://blogs.technet.com/rhalbheer) and if we would do something like a driver’s license worldwide we most probably would kill a lot of efforts getting people out of the slums.

Why should the security of an operating system depend on the intellectual strength of the user when the safety rating of a car is agnostic to whoever the driver might be?

Because the consumer has a gazillion of not controllable option to mis-configure the Browser, the applications and the OS as everything is multi-purpose. This is the big, big difference between a car and software – and it is product agnostic.

When I look at the discussions we had on this blog, we should at some event in time actually run a podium’s discussion – would be pretty interesting :-)

There may certainly be idiot drivers, but on the whole the car’s safety rating is agnostic; that is, the car is “safe” no matter who the driver might be. Whether the driver drives *safely* is another matter entirely.

In the software market however, the security (analogous to safety in vehicles) of the operating system largely depends on the user; that is, is the system configured correctly to protect the software itself from exploitation. This is far too brittle a model; it doesn’t scale reliability, and how in the world are 500 million users supposed to get all their configurations correct? Configuration, in large part, is a red herring that distracts from the issue.

So to say that an “operating system is only as secure as the idiots using it” is not only accurate it touches on something that is wildly unfair.

Drivers do not need to configure their vehicle’s crumple zones, side impact bars, or seat belts (besides adjusting) to receive protection. These are safety feature IN ADDITION TO good and safe design of the vehicle, not REPLACEMENTS FOR the lack of good and safe design. Compare this with your typical computer system. The user must configure almost everything (ACLs, firewalls, etc) including the roadway (the router) not, as with vehicles, in addition to good and secure design of the operating system, but largely as a replacement for the lack of good and secure design. This isn’t fair. As a matter of public policy, it is unjust.

In 1950s and 1960s America, the car companies could freely, and without danger of appearing hypocritical, point to drivers and say, “see, it’s the nut behind the wheel that is causing all these roadway fatalities. It’s not us.” When in fact, it was to a large degree a manufacturing issue. Sure, drivers had SOME culpability for roadway fatalities, but not ALL culpability as the manufacturers made it appear.

In today’s software market, the same situation exists as it did in 1950s and 1960s America. Software consumers are “the nuts behind the keyboard,” the “idiots” as they are deemed. It is software consumers that are blamed extensively for not configuring their “vehicle” correctly. But this doesn’t make sense. Why in the world should we blame users for manufacturing defects that could not possibly be their fault? Why should the security of an operating system depend on the intellectual strength of the user when the safety rating of a car is agnostic to whoever the driver might be? According to my elderly mother, plenty of idiots are on the road today, but you’ll note that the U.S. has held steady the number of roadway fatalities at roughly 40,000 per year despite over an 80% increase in traffic since the 1980s. More “idiots” are driving – and driving longer distances – than ever before, but the safety of vehicles remains agnostic to both potential and latent idiocy.

Certainly, if someone drives drunk, they are culpable, but culpability is bounded. What if the wheel falls off their car at highway speeds (or their fuel injection system crashes as it did with GM and Prius vehicles).? Are the users to blame for manufacturing defects? In the software market, culpability is unbounded. Software consumers are blamed for any failure to protect their systems, manufacturing defect or not. Why should software consumers be liable for manufacturing defects in software products? The lack of consumer protection and the imbalance of culpability in the software market are truly astonishing. To expect 500 million+ users to configure their systems correctly in order to receive suitable protection is not only unjust, it is barking madness.

Thanks for the opportunity to post and for leading a great discussion, Marcin. Cheers.

Mom and dad can understand five-star rating systems fine. The problem I see is relating exploit countermeasures and architectural security enablers (e.g. network devices, network features, HIMS, HIPS, and DLP host features).

Transparency and fairness have to be as crisp and cruel as possible. Software vendors and developers actually do get away with murder, as seen by the FDA QRS regulations that have occured over the years. The five-star rating system I’m suggesting is more akin to the food safety regulations in place, rather than my preferred metaphor of using the NHTSA’s New Car Assessment Program. However, as you can see in Safecar.Gov’s frequently asked questions, they are using crash test dummies in order to provide a rating system.

We can’t use crash test dummies for our software security assurance rating systems because WE’RE the crash test dummies… the users of the applications. So, instead I turn it back on the code. In food safety, there are instances of E.Coli and other diseases - some of which can put a company like Topps completely out of business (remind you of the CardSystems data breach?). They use regulated samples and microbiological testing (partially automated with “plating” using incubators, but still requiring manual inspection to rid the occasional false positive or false negative) in order to pass meat as true negative on diseases or bacteria that could kill or injure humans. These samples are typically chosen based on the worst color and smell, which is usually easily identifiable.

With software code, we have software quality metrics (e.g. Cyclomatic complexity, defects per NCSS, and the rest I named earlier) and code coverage to provide the “colour/sniff test” about how good or bad the code and/or testing is. Then we can add automated static code analysis and/or automated application fuzzing and fault-injection (similar to the “plating” technique to detect disease in meat). I’ll just straight up name those best of class tools: Fortify SCA (automated static source code analysis), FindBugs (automated static bytecode analysis), jCUTE (automated application smart fuzz testing), and IBM AppScan DE (automated application fault-injection). There are a few methods such as the Evolutionary Fuzzing System (EFS) and fuzzing frameworks (e.g. Sulley Fuzzing Framework) that can be utilized when attempting random or smart fuzzing. Smart fuzzing usually require a formal model (also see model checkers such as Coverity PREVENT), source code, and/or protocol descriptions - otherwise they will require protocol dissection (i.e. put the “smarts” into Sulley or Peach Fuzzing Frameworks). If source code is unavailable, tools such as FxCop, Veracode SecurityReview, Fortify Tracer, and possibly others can be used on bytecode - while binary code coverage can only be hit-traced with a technique such as process stalking available in the PaiMei tool.

Once the above testing is independently reviewed - an application rates as some sort of “percentage security-related bug-free”, which will ultimately determine the five-star rating systme that mom and dad can use. Unlike meat, not all software will have to contain zero bugs like meat has to contain zero amounts of E.Coli before sent to grocery stores - but my model handles things like “false positives, false negatives” - which the automobile metaphor system fails to deal with - let alone where we get anywhere less than 6 billion crash test dummies.

We would need a clear set of criteria and then …. Wait a second. Didn’t we try this already?

I don’t think we’ve tried what I’m talking about. I’m talking about secure code that is CWE-Compatible and CWE-Tested.

There were a numerous standards out there and most of them fail in my opinion. The reason is that they are certifying a single state of the software in a single configuration. This might make sense if we are not allowing the users to change something at the configuration. But what happens if Windows Vista would get 3 stars out of 5 (just guessing, I would expect it to get 6 ;-)) and the user then switches off the firewall?

The NHTSA NCAP five-star rating system for cars also does not assume that people will wear seatbelts, drive sober, have a license/insurance, or drive on non-trecherous ground (an Interstate highway).

Which is exactly why I already mentioned most of these things. Exploit countermeasures, whether Microsoft DEP or software firewalls need to be “put on” in the same way you put on your seat belt. Sure, there are people who “opt-out” of seatbelts because it “messes up their dress” or “squishes their fat”, but I assume most of us know that seatbelts save lives.

Also - users shouldn’t be able to turn off some essential features and they should be able to trust those features. Software firewalls are optional because they affect users being able to connect to other users/services, or they affect performance - and sometimes are turned off because the user is unsure about their network connection in the first place. Not everyone needs rollbars, suspension systems, and helmets while driving - yet some professional drivers rely on these to live. We need to come up with exploit countermeasures and configurations that work for everyone (mom and dad) just like seatbelts do. Optional features for security professionals can always be made available in forms of driving gloves, sunglasses, or helmets - but these should be optional, not mandatory, for application security assurance.

Additionally, this would become a commercial label. Everybody would want to get as many stars as possible, leading back to the need of having a joint and fair set of requirements to distribute the stars

I will do everything in my power to prevent this from becoming a commercial label. By working with OWASP (and Mark Curphey) on the Web Security Certification Framework, Fortify on the Java Open Review Security Metric System, or possibly MITRE on a CWE-Compatible or CWE-Tested program… I think that I can keep this out of the commercial space.

What is even more likely to happen is that the US Department of Homeland Secuirty’s BuildSecurityIn program will pick something like this up when working with MITRE and NIST. So if we don’t self-regulate (like PCI DSS), there probably will eventually be government regulation. I’m fine with it as long as it saves lives and my mom’s credit card number is safe on a month-by-month basis. I also like to breathe air, use ATM machines, and go to the hospital without terrorists making those things an unreality.

Would making the code public solve the issue?

No, but note that I’m not suggesting that, per-se. I’m saying that before code samples go for independent review - they can also optionally be open-sourced. For an exmaple of this, check out Apple’s WebKit, which includes code coverage information and can be readily downloaded by anyone. It was this code “sample” that was used to find the bugs on the iPhone (via the Safari browser, which contains parts of that code) and provide a path to its exploitation.

Next I would like to comment is code signing. I am a big fan of code signing – unfortunately a lot of hardware vendors and smaller ISVs are not. When I talk with some of them about it they tell me that Microsoft then just forces them to spend money “for nothing”. They claim that we are misusing our market share in order to drive revenue of the companies issuing certificates. These are not made up statements but statements I am hearing very, very often.

It’s just another exploit countermeasure. It works for some, and not necessarily for the masses. If it did work for the masses and nobody complained - I bet our application security assurance would go way up.

Coming to the last point: The significance of the different areas of security. When I find the time I will start a series of blog post around what I see to be the key drivers at the moment and what that means for the companies. I would love you to comment (once I am done)

Sure. Are they anything similar to the stuff I’m talking about? Am I totally off-base or living too far in the future?

A key problem to me when I talk to customers or governments is to make them understand that persistent protection of the data is key! But that does by no means mean (from my point of view) that you can now de-invest in your network protection. These are different threats you are addressing but the risk profile is shifting heavily

I agree with this, but see the “shift” you are talking about as a way of rebalancing the typical IT security budget so that half of your spending on network security is shifted to software security assurance and data leakage detection/prevention.

There are more topics to address: such as drivers licenses, insurance, paved roadways and interstates, as well as an in-depth analysis of protection mechanisms. However - we never would have had these or know about them if we didn’t give the car manufacturers incentives to increase their five-star safety ratings. It’s a good starting point for software security assurance, as well.

Let me try to comment a few things:

I basically love the idea of rating software to kind of create a “security label”. The challenge there will be to find a way (as you stated) to make it transparent and fair and understandable by my mom and dad. We would need a clear set of criteria and then …. Wait a second. Didn’t we try this already? There were a numerous standards out there and most of them fail in my opinion. The reason is that they are certifying a single state of the software in a single configuration. This might make sense if we are not allowing the users to change something at the configuration. But what happens if Windows Vista would get 3 stars out of 5 (just guessing, I would expect it to get 6 ;-)) and the user then switches off the firewall? Even if the software would be secure in the first place, security would be reduced significantly. Additionally, this would become a commercial label. Everybody would want to get as many stars as possible, leading back to the need of having a joint and fair set of requirements to distribute the stars. Would making the code public solve the issue? Well, open source OSs prove that this is not happening. A lot of governments and big companies have access to our source and sometimes certify our products that way for classified environments. Does this improve security of our products? I doubt. However, if we would overcome these problems, I would love the idea.

Next I would like to comment is code signing. I am a big fan of code signing – unfortunately a lot of hardware vendors and smaller ISVs are not. When I talk with some of them about it they tell me that Microsoft then just forces them to spend money “for nothing”. They claim that we are misusing our market share in order to drive revenue of the companies issuing certificates. These are not made up statements but statements I am hearing very, very often.

Coming to the last point: The significance of the different areas of security. When I find the time I will start a series of blog post around what I see to be the key drivers at the moment and what that means for the companies. I would love you to comment (once I am done ). A key problem to me when I talk to customers or governments is to make them understand that persistent protection of the data is key! But that does by no means mean (from my point of view) that you can now de-invest in your network protection. These are different threats you are addressing but the risk profile is shifting heavily. If you look at our Security Intelligence Report for Jan-Jun you see an increase of Phishing Attacks by 500%! Which kind of underlines that network protection and classical protection of the data (including file/folder encryption) are no accurate security measures – for attacks that try to impersonate you.

So I think, looking at your feedbacks, that we are pretty much in line where the future shall guide us. Additionally I think that the industry made big steps forward. Unfortunately there are still companies that do not get it (yet).

Does this make sense?
Roger

While reading, “Geekonomics: The Real Cost of Insecure Software” and speaking with people at Fortify Software, Veracode, Cigital, and MITRE… I’m sold on the concept of a five-star “software security assurance” rating system for both commercial and open-source software to solve the “stem” of this user+security problem.

My criteria for this rating system is unique, but you may enjoy the approach. Take the most complex code (i.e. Cyclomatic complexity), historical and trend data on code (using other metrics such as defects per NCSS, class coupling, depth of inheritance, maintainability index, etc), areas of code with the least code coverage, and statistics/trends from secure code review reports. Blend all the data together using a balanced scorecard or other 6S tool.

Now, provide that stats data and code snippets to at least three neutral third-parties, or better - open-source it. Send your “ugly code samples” (the worst you can find of your own code) and let them have it. Even better - send parts/pieces of components that are the most critical to the security assurance of your application (e.g. a web browser tied to an OS explorer, the transactional components of a credit card processing system, etc). Let your third-party evaluators determine your five-star rating system score based on this code, allowing them to build the code and use dynamic analysis with fuzz testing (as well as secure code review).

Finally, get the five-star rating system published everywhere, on the software boxes, in newspapers, magazines, and everywhere the product name goes. Make it a part of consumer reports; make it the most important part of consumer reports. Make sure that expiration dates are also published with the ratings, and have a place online where people can go to check all the latest information on their software security assurance ratings for all the applications that they use.

This is just touching the surface of some of the problems. For the “click on this link” problem - education will eventually work long-term (but not for mom and dad - only for children growing up in a world where knowledge about software security intricacies will be a part of survival of the fittest).

However, immediate controls can be put in place to make browsers safer (the source of this whole “click a link” problem). These are covered in detail on the GNUCITIZEN blog under XSS Worms and Mitigation Controls, which will equally apply to all Javascript and browser-based malware (and not just XSS-based backdoors/worms/etc). These measures equally apply to man-in-the-browser, man-in-the-middle, browser-based rootkits, as well as classic backdoors.

Just like operating systems, we need to provide software security assurance in levels to the browser. The first known implementation of an orange-book assurance system for the masses were the trusted path execution (TPE) patches for SLS Linux, coded in late 1994 and made available in Phrack issue 52-06. I believe Windows 2000 also made some improvements to using a trusted path, which was enhanced in XP and SP2, and probably further in Vista.

HttpOnly is an example of creating a trusted path of execution for the browser, unfortunately HttpOnly has a few problems. A better answer would be content-restrictions, which is a project by Gerv that never made it into Firefox.

Trusted path of execution is different than the privilege levels and more like “sandboxing”. I don’t often buy into privilege levels as increased software security assurance, but that’s a different argument. It would additionally be nice to sandbox Internet from RFC1918 in browsers, especially for some controls. See the XSS Worm Mitigation Controls comments about links to Jeremiah Grossman’s blog regarding this particular matter (as well as other browser-based privilege and sandbox ideas that are quite excellent).

The next logical step would be to sign binaries, as implemented in XP SP2 and Vista (as well as other projects such as Linux DSI/DigSig, and earliest in FreeBSD circa 1997). Mac OS X doesn’t really have signed binaries - even with their latest release, Leopard (where codesign appears to be a failure).

In the XSS Worms and Mitigration Controls article, Tim Brown claims that Javascript code signing is the penultimate solution for XSS mitigations. He really may be on to something here.

As for building the correct privilege models, knowing when/where/how to sandbox functionality, and when code signing or other exploitation countermeasures go from useful to “absolutely necessary” depends on design, operations, and architectural review of modern-day applications - as they are built - and as they are targeted by adversaries.

In the 1960’s the NHTSA made it so that your mom and dad could live their lives without increasing probability of getting in a car accident and dying. They implemented a five-star rating system for safety.

But the five-star rating system also increased public awareness of safety “features” such as seat-belts, missing seat-belt warning indicators, air-bags (how many modern cars have the word “air bag” in various places all over the vehicle?) and the use of crash test dummies in order to pass vehicles through safety inspections.

50 years ago there was not a single manufactured car that included seatbelts, and it took many years for people to even understand what they were. I still see people confused on airplanes as to how to use their seatbelt! It took over 20 years for airbags to make it into vehicles, but I think many people now understand the advantages.

When my mom and dad can explain in detail what ASLR is just like they can explain what an airbag is… then I’ll be happy. Maybe Microsoft should call ASLR v2 “Microsoft Airbags”? My point here is that a five-star rating system isn’t going to solve the problems all by itself - it has to get popular and people need a basic understanding of how the safety/security features work - in addition to well tested code.

Many IT managers, developers, and administrators do not understand the significance of the need for a Javascript sandbox. Wait, let me change that sentence. Many browser project managers, developers, and users do not understand the need for a proper Javascript sandbox. I’m typing this in a different browser instance with NoScript, CookieSafe, and LocalRodeo. Do I feel fully protected against Javascript malware? No, not at all. Would I feel safer with code signing? Yes, a bit.

However, even with the security features - it does not make a secure product. Besides deeply rooted and severely horrible architectural and design problems for browsers - there are additional problems. First of all, they are written in C/C++ and allow toolbars and other functionality to be added in various ways. Secondly, as the “only client” that is used to interact with Web 2.0 - the browser is a single-point of failure in the security-chain.

Let’s just say that IE7 and Firefox 2.x.x.x wouldn’t even make a single star if such a software security assurance five-star rating system even existed, and the expiration date would be at least 2036.

There is another way to combat the “click a link” problem, and it’s to find the “sinks” of the issue. Honeyclients and threat intelligence should be a major effort, however - we do know that this is a losing battle. The anti-phishing protections in modern browsers are a joke (adversaries will just move to PDF vectors, etc) - even Bleeding Snort with real-time blackhole lists and OpenDNS only scratch the surface of growing amount of adversaries building botnets and spreading threat agents such as Javascript malware. Firewall, anti-spam, AV, NAC, IDS, and IPS (both network and host-based variants) are not helping to reduce the threat problem to any degree that they used to (if they ever did). Network and endpoint security is dead, right?

Organizations must re-purpose their IT security spending so that more than half of their network/system security budget goes directly into software/data security assurances, especially if they haven’t made any changes to those budget levels since 2004. In 2005-2006, there was a major shift away from “classic” vulnerabilities such as data reference vulnerabilities in parsers to input-output “Web 2.0″ faults.

Software vendors and users also need to re-adjust their spending (time and money) to shift towards software (third-party applications they run on Vista) and away from systems/networking (I would argue that with WiFi security issues, CSRF and drive-by pharming, etc - it’s safer to NOT have a home router-firewall device than to have one).

We live in a world where an adversary’s favorite targets are in Enterprise applications (e.g. AV agents, Word, PDF’s, etc). In some cases, it’s almost safer to NOT have an AV than to have one. Strange times indeed. However, there is also a big move to protect data (DLP, “extrusion prevention”, et al). I think this will largely end up being a mistake, especially since the products are not mature enough yet to hold water… again with little or no independent review. The strategy/tactics of DLP are worth investment - there are plenty of clipping services (Google Alerts anyone?), Honeytoken concepts, and digital watermarking services available to enforce stricter controls on data leakage.

While some may feel that data security assurance is the new silver bullet, I would tend to remind everyone that we thought the same when we put all our eggs in the baskets of OS security, server security, network security, and endpoint security. So, if you’re going to spend money or resources - spend them on software security assurance, in particular: third-party applications.

How does one “secure” third-party code? Well, you can legally do this by using secure software contract annexes along with certifying each vendor’s code/products through a home-built process. The OWASP (Open Web Application Security Project) has information on software annexes, and we’re working on building a web “certification” to do the same. Other modern applications could be put through a similar process - it’s not only for web applications.

The basics of a secure software process are alive in the Microsoft SDL (Security Development Lifecycle), but I think Microsoft does miss the mark on how to integrate tools, automation, and workflow of this process (I’ve heard that Michael Howard is changing his view on this slightly as of late). Using Continuous Integration (along with security-specific “point” tools such as Atlassian Crucible (workflow for code review), Fortify SCA (automated static analysis), Coverity PREVENT (model checking), Microsoft FuzzGuru (fuzz testing at build time), and HP/SpiDynamics DevInspect (fault injection at build time), as well as similar tools in the same vein - software security assurance can be increased without heavy investments or “soft” investments which take time (although combining statistics from these tools into 6S tools will require baselines and trending).

However, for these tools to be truly powerful - they must be tuned from work done via early-on design review (i.e. threat-modeling, attack-modeling, etc) as well as gathering useful requirements for abuse cases / abuse stories. Some of the tools that enhance these processes include Atlassian Crucible (Fagan inspection works through the entire lifecycle, not just code review), the NASA automated requirement measurement tool, Octotrike, Practical Threat Analysis, Microsoft’s TAM tool, and the Amenaza SecurITree software.

Last of all comes operational and architectural review, where exploit countermeasures (e.g. ASLR, grsecurity, et al) and network devices such as Breach security (or a reverse-proxy mod_security device), Palo Alto Networks, Trusteer.com, Imperva SecureSphere, FortifySoftware Defender, CORE GRASP, PHP-IDS, dotnetids, and even “client-side” IPS/NAC (ones that can see into SSL-based HTTP POST operations such as BlueCoat and get “deep” browser info such as RSnake’s “Mr.-T” or Jay Beale’s Squid-based ClientVA project). If you’re still stuck on the whole network/system/data security solutions - at least spend your money and time on these sorts of products, and with special regards to integrating them into your environment and operations procedures. Or you could buy donuts for your developers once a week…

Others believe user education is the way, but even so-called “security professionals” are duped as well. Take for example the infamous “kiosk” incident at RSA 2006, or even better, the DefCon Wall-of-Shame. I don’t think we can count on awareness and education alone.

A former colleague recommended to me Security Engineering by Ross Anderson, which I will add is a great book. Security is hard, and to get right even harder, and it’s never guaranteed. Same colleage also pointed out Security and Usability by Lorrie Cranor and Simson Garfinkel, which is a collection of groundbreaking papers published on the subject. I even think security teams should start looking into hiring staff psychologists with a background in security to help us understand how users think. We as geeks take a holier than thou approach sometimes, and forget to walk in the shoes of our uses. We certainly don’t want security to be the Mordac, as seen in