One of the concepts that I think gets heavily overlooked in security is the idea of an assurance – the degree of protection a specific control provides. When speaking about assurance the discussion is how resilient a control is to attack; controls easily thwarted offer low assurance, controls very difficult to bypass offer high assurance. A 4 digit numeric password offers a lot lower assurance than an 8 character mixed case, alpha numeric password – other authentication policies being equal (account lockout on failed attempts, dictionary checks to ban common passwords, etc.), which in turn is lower assurance than an said 8 character password combined with some form of second factor (token, smartcard, OTP, etc.). Each of these provides very different resistance to the various automated attacks on authentication (targeted attacks, more often than not, exploit the user rather than the technical controls, though a second factor does provide more assurance relative to that as well).

NIST in their 800-63 Special Publication uses the concept to discuss authentication, mapping password policies and additional authentication factors to assurance levels (the levels are set by the sensitivity of the user role – the more sensitive the role the higher the assurance needed for the controls protecting accounts belonging to that role). Personally, while I do not think every organization should adopt the NIST publication as is, I think they should adopt the spirit of it when evaluating authentication policies. Too often the controls around authentication are qualitatively arrived at based on the gut feelings of someone in the company (if lucky, a security person, but how many AD account policies were decided by some random IT person). This model is a means of actually quantitatively trying to ensure that the controls are adequate.

Talking about assurance is very useful for a number of reasons. Using the example of authentication above, one of the most common questions from business people who believe a product’s password scheme is overly restrictive and offsetting to customers is “How likely is it that someone is actually going to hack our passwords to gain access” (as a quick aside, the real issue with passwords is that they are an all-around terrible control). Discussing password policies in that context is a losing venture – there really is no means of quantifying that likelihood. There are just too many variables without means of measurement – how do you come up with a probability that a person with the technical knowledge, inclination AND opportunity will attack the application/control? Switching the discussion from likelihood to assurance changes the conversation from defending a decision where you can’t possibly have concrete data to one in which you can. What the conversation then transforms to is the general tolerance the organization has for account compromise and how to engineer controls such that that tolerance isn’t exceeded. That is a much different conversation, and much more productive than guessing about the likelihood. It also is much better for the company – even if likelihood could be incredibly accurately predicted – if we knew the probability to 100 significant digits – it would still provide no protection. A probability of 1 in 1000 doesn’t mean it doesn’t happen, but that out of a thousand it will happen once. That something is incredibly improbable doesn’t help an organization at all if they happen to be that one.

More importantly though, shifting to a discussion of assurance and tolerance level moves software engineering to a model much closer to traditional engineering. When building a skyscraper there isn’t a discussion for the probability of an earthquake. Rather the engineers design the building to be resistant to a certain degree of seismic disturbance. This is a distinct change in how we discuss software. How many software teams have a discussion up front for their tolerances for certain types of failure? Actually quite a few – but their focus is on performance and availability. Conversations happen all the time around up time (we need 5 nines of availability for this, etc) that are very much in this vein, but they are largely the exception. What we as application security folks need to do is move that conversation to include other areas where it makes sense to define tolerances and engineer to assure those tolerances aren’t surpassed, whether it is the authentication system on our web app, the cryptographic storage on mobile clients, or any of the myriad of other areas where we consciously need to make decisions on protective controls. It also applies to general application quality where similar tolerance levels can be defined and engineered to.

~Joshbw

Two talks at RSA last week helped galvanize a concept for me that has been kicking around unverbalized in my head. I have long thought that things like CSRF are problems that developers *shouldn’t* need to worry about – they are a fundamental design issue with the web that requires custom coding in each application to rectify. This holds true for many (all?) of the other implementation level issues as well. Our strategy for application security is to make developers aware of all of the potential problems and put the responsibility on them to code around the problems because we haven’t come up with a better option (but we have, and I will get to that). The art of writing code is simultaneously seeing the big picture and the small picture – understanding how each individual statement builds towards bigger functionality. That alone is a fair amount to simultaneously track, and every concern or complication that the developers have to be aware of at the statement level increases the chances that they will make a mistake.

Brian Chess (of Fortify Fame) gave a great talk last Monday at RSA as part of the AppSec symposium, where he discussed why Buffer Overflows still exist even though we know the technical cause. He had a great demonstration of how many decisions a developer needs to make in a single line of code to get some derivative of sprintf to be safe from an overflow (it was either 6 or 8 decisions, for what amounts to a pretty simple buffer transfer). That was the eureka moment for me, where my own thoughts came together – the cause of Buffer Overflows isn’t buffer manipulation per se, but rather that the developer needs to simultaneously be aware of many conditions and get every single one of them right. How many other implementation level vulnerabilities are the same way? We know that managed languages mostly cure buffer overflows (edge cases like the C# Unsafe keyword not withstanding) but I think we chalk up the reason why to purely technical concerns. What we miss is that the technical concerns are a result of a coherent design decision – automate the memory allocation for strings so the developer never has to be aware of it.

The second talk that reinforced this was by Alan Karp of HP Labs. He was demonstrating an analog to email file sharing that hid all of the security decisions from the user; his little app automatically used SSL for all communications, automatically applied ACLs to the files being shared, automatically had user authentication built in to restrict file access, etc but look to the user just like the normal workflow for sending a file via email. In practice I don’t think we need one more way to share files, but as a demonstration of security concepts, where security is implicit rather than explicit, it worked.

Right now AppSec is very tactical. We are trying to fix the immediate problems through developer education and add on security frameworks, and as a stop gap that’s fine. For a strategy though, I think the various custodians of the languages/popular frameworks (MS, Oracle, SpringSource, the Apache Foundation, the PHP group, etc) should make a conscious decision to change the languages/frameworks to hide the default security decisions from developers in the exact same way that the move to managed languages hid buffer decisions. Add whitelist validation implicitly to the various parameter retrieval functionality based on the current character set, so that every time the developer accesses a parameter it is automatically sanitized (as an aside, I think languages should not automatically mix retrieval from Cookies/Get/Post variables). If the developer wants to deviate from the implicit input validation then have an unsafe version of the retrieval mechanism that they have to explicitly invoke (in the same way that you have to explicitly use the Unsafe keyword in C# for memory manipulation); that would still allow the current flexibility but it would make such a choice explicit for the developer and make flagging areas for manual code review very easy. Replace the current SQL with a query language completely immune to injection attacks (essentially something like LINQ); yes we have parameterized queries now, but they are an opt-in solution. I think languages or frameworks should instead move to opt-out solutions. Take the notions of ViewState the full distance to prevent CSRF (since they only *mostly* protect against CSRF now, and are obviously MS specific) and make that the defacto mechanism everywhere. And so forth for as many of the implementation level issues as we can. So long as we put the burden on the developer to get everything perfect they will continue to miss things, because humans just aren’t perfect. We need to move a lot of that burden to the languages or frameworks the developers are using, just as we did to get rid of Buffer Overflows.

Yeah, it will break a whole lot of backwards compatibility. Yes a migration path will be hard and it will only work if we can get people to migrate. But in yet one more RSA there continues to be a whole lot of talks about how we are still losing at AppSec (with folks like Verizon providing hard data to prove it), nothing but false promises from vendors to fix the problem, and the best strategies (education and verification tools) being no different from 5 years ago. I think more drastic and ambitious attempts are really in order.

~ Joshbw

WhiteHat security has recently released a paper where they attempt to answer “What is the most secure programming language or development framework available?”. There are two very good responses to the paper from Michael Coates and pInvoke which are well worth the read.

Ignoring the multitude of issues with the actual methodology (scientists WhiteHat is not – if this paper gets published in a proper journal that journal has some low standards) I have issue with the actual question. What on earth do they mean by “Most Secure Development Language/Framework”? If they mean the language or framework whose runtime or libraries will most likely have attempts to break the framework or language that will already be a hard thing to measure. Do you measure the NVD numbers for vulnerabilities discoverd in the language or framework (PHP I think you lose Mr. 18,000 and counting), the severity of the vulnerabilities, the exposure window between discovery and fix, effectiveness of patches to address the issues, etc? How do you create a metric when the Linux and Windows, Firefox and IE teams (and really every internal AppSec organization in an enterprise) have been argueing over a good metric for ages with no agreement. That said, having some measure, even if not agreed on, is a useful thing because the security of an internet facing application isn’t just dependant on the code an enterprise writes, but also the 3rd party code exposed to the internet. It would be useful to know how Tomcat stacked up to WebLogic in terms of security while I am making my decision of which server runtime to use.

That would be a literal interpretation of “Most Secure Language/Framework” because you are measuring the security specifically of the runtime/framework code. Whitehat does not mean this however. What they mean is which language will produce more secure websites, which is neither an appropriate question to ask, nor one that they have answered reasonably (see two other links above). Thinking completely ideologically, a better question would be given the following languages and frameworks, which will prove to take my developers the least amount of time to implement the following product with a minumum of critical, high, and medium severity vulnerabilities? Do the languages have features that make defending against certain vulnerabilities significantly easier and less time consuming, and thus save me development costs? Do those security features come at some cost that increases development time elsewhere? Alternitively, are their design decisions in the language, or a lack of features, that have to be engineered around to make a secure site, and how much time does this cost (for example, PHP before it had prepared statements – that is an inherent handicap).

An incredibly competent and methodical C-coder could make a CGI based website just as securely as an incredibly competent and methodical C#-coder could make a MVC.net 2.0 website. The C-coder certainly has a heck of a lot more hurdles (a little something called buffer overflows, for starters) but there isn’t a technical reason that makes certain vulnerabilities absolutely unavoidable. If I am making a language decision for my enterprise the fact that it isn’t technically impossible to make a secure website in a particular language doesn’t matter to me – what matters is that it is going to take the C-coder many times as long to spit something out as the C#-coder. So the useful question isn’t “Which language/framework is more secure” but rather “Which language/framework makes it EASIER for the coder to produce a secure website, and do so quicker” and the WhiteHat paper doesn’t address this. In fact their methodology makes answering that question impossible. The only real test would be to stack up balanced teams of comparable skill at each language and have them implement the exact same website, then measure how fast they produced the site, how many vulnerabilities were initially detected by equally balanced pentesting teams, and finally how quickly it took to fix the vulnerabilities.

I don’t see that test happening soon because that is a fairly non-trivial amount of work. It also would only tell you something about that specific type of application. A website with dramatically different design considerations, or a web service, or other type of application may not have the same results. That said, in general I agree with pInvoke in his writeup above that the Microsoft stack does offer some very obvious built in advantages, from preventing CSRF (encrypted view states, to my knowledge the only framework with such a protection built in) to the trivial input encoding, that can be compared to other languages without having such a thorough experimental design.

All of that said, for any given organization the languages that are probably the most secure are the ones the developers are most comfortable writing code with. Forcing a PHP developer to write mvc.net code because you feel it is more secure is a mistake and will buy you nothing but a longer development cycle. (exception – if your coders still swear by CGI you really are better off forcing them into something invented in the past decade even if they will have a learning curve. You probably shouldnt’ have let them be so resistant to change to begin with).

~ Joshbw

An old and well worn addage is “Do as I say, not as I do”, generally in a fit of hypocracy when the listener is asked to ignore the example being set by the speaker. The fallacy of that statement was addressed by the series of “I learned it by watching you” advertisements trying to drive home the point to parents that children are more likely to learn from example than from what the parent says.

In the Applications Security space we are big fans of telling developers what they should and shouldn’t be doing in order to produce secure applications, which is all well in good so long as we are not violating those very same instructions within our own properties. If developers are visiting their enterprise’s security portal and see examples in practice contradicting the secure coding and design standards on display on the very same portal, it completely undermines those standards.

Having raised this more than once and been given a liteny of excuses of why it is acceptable (there isn’t anything of value on this website, we wanted to get the content up now and we can always go back and fix the problems, it is only for internal employees anyway, etc), the same excuses that developers of any other project will put forth for why they don’t need to build security in for this release, I really wonder about the effectiveness of the message the application security community is trying to convey. If we can’t even get our own organizations to embrace our suggestions, obstensibly folks that “already have the religion”, what is our hope of getting converts to that message elsewhere.

So for various security organizations, the risk profile of your application is not an acceptable excuse to ignore your own security recommendations; if you are not going to abide by your own mandates do not bother asking others to do so. “Do as I say, not as I do” is a very ineffective strategy. Developers WILL notice your lapses and no amount of trying to create a justification of such a lapse based on the risk profile of the application in question will buy you any crediblity to restore that which was just lost. The risk is not to the confidentiality or integrity of the application, but rather to the integrity of the message the security organization hopes to convey. Even if the underlying message is completely valid, a kid being told by a parent presently working through another pack of cigarettes for the day isn’t going to buy that they themselves shouldn’t smoke.

And a special message to OWASP, the same applies to you, and your various caveats throughout your website do not make it ok to ignore your own advice. Saying

“You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext. “

when subscribing to a mailing list is not OK. It doesn’t matter that there is little security risk even if someone does compromise the password – the entire point of this post was to establish that security risk is not the only consideration. You undermine your message when you choose the easy route – why should I hash my passwords when it is obvious OWASP, whose job is communicating security, doesn’t think it is important that they do.  Similarly, I think it would be great if you set “AUTOCOMPLETE=off” on your login form, like you suggest in your various coding recommendations, and similarly switch to a generic message if either the username or password is wrong, rather than telling me that specifically the username or password is wrong. Incidentally, MediaWiki would be all the better if you had those changes adopted into their mainline branch, which is the least you can do having leveraged the project.

~ Joshbw

It is a truism in the application security world (or really any security) that in order to have an effective Security Program you need executive buyoff and executive support. To many this means that you need executives to care about security, be willing to fund it, and be willing to stand behind their security personel. This is certainly true, but there is a precursor step that is necessary for many development organization to move to truly institute effective Application Security – they need to mature as a software organization and embrace process.

When most software organizations start out they often embrace a seat of the pants development style, something often mistaken this as agile development, which has three very simple steps – Have Idea, Code Idea, Market Idea. As they mature they might realize that they should decide if they can sell the idea before they try to code it, rather than figure that out after the fact, and they decide they need to bring in testers to verify that they actually did code the idea. As a dev org matures they get to a platue were they have developed some process, but it resides on either side of the developers- they actually do analysis of an idea to see if it is worth the development costs, and they do testing and customer acceptance verification to make sure that the idea was implemented in a way that will meet customer’s needs, but at the end of the day all they expect developers to do is write code and testers to make sure the code does what it is supposed to.

The problem is, that is an arrangement that will not consistently produce robust code- security wise or otherwise. Verifying functionality only finds average use case flaws, but does not verify proper behavior across all concievable uses, and simply writing code without discipline will produce unmaintainable, fragile, redundant code. It is in this state that organizations start to care about security, but they aren’t willing to make real commitments to the changes necessary to see it happen. At this point they need to decide whether or not they are willing to change their development and test culture, and this is a very difficult decision to make and enforce.

If the decision is not made, the organization will trap themselves into an entirely reactive model to security threats- Problems are found by vulnerability assessment or customer reporting and fixed- tribal knowledge is gained among some developers and there is a short term downtick in that specific type of vulnerability among those specific developers- long term the org hasn’t learned much, and the information is not sustained. Almost no prevention will occur. This is because a preventitive model would require changes to how the code is written and verified.

If the decision is made, then the development team needs process placed on them and accountability to following that process. They can’t just write code anymore- they need coding standards detailing how they can write code and they need to get used to writing documentation. Developers hate writing documentation, but it is one of the most important things they can do- with documentation they can fully think through how they will code a feature before they start doing so (we don’t start pouring foundation before we decide on the blueprints for a house after all) spotting shortcomings of a particular method before they have spent a couple of days implementing it and they will provide something were the design itself can be tested rather than just the implementation. On the topic of testing, the dev org needs to get in the habit of hiring testers who are very skilled at thinking in terms of finding problems, rather than testers who are little more than stupid users that can determine whether a feature either works or doesn’t. Skilled testers are worth as much as a skilled developers, as effectively finding technical problems is just as hard as effectively coding solutions (one of the best interview test questions I have ever heard was “What do you think of your cell phone?”- a true tester may describe a couple of things they like, but then proceed to talk about the myriad of things that they wish were done better. A true tester is someone who perpetually sees the flaws in something, no matter how good it is). The testers also need to be given a strong voice- they are the verification for the developers and if their voice is not strong, then they can’t serve their purpose.

Doing this will give the security team a framework to then build in security controls into the development process. They need an actual process in place, otherwise they have no foundation to build off of. An existing and well defined development process is an input into any effective secure development lifecylce, and an SDL is ultimately the path to a preventitive approach to security. The problem is that it is very hard to change a development culture and it requires commitment from the top. Developers hate process, and they are going to be very resistant to implementing it. Executives need to make it abundandly clear that conforming to the process is the developers’ job- it is what they will be paid to do, and if they don’t do it they will not be paid. This will make no friends among the developers. That is why it is the hardest decision that a maturing development organization can make.

Incidentally, the same thing is true for OSS as for proprietary, however it is even more difficult to implement and enforce in an open distributed development environment. The payoff for either software is much more than just security- the overall quality of the product will improve as a result and the code will be easier to maintain as their will be documentation to refer to and a level of code quality enforced.

~ Joshbw

CGI Security via AppSec Notes complains that Netflix has not fixed all of their CSRF vulnerabilities. You can no longer access account information, billing information, change shipping address, or anything of value, but you can still add movies to someone’s queue. This apparently still bothers the author who has a note of annoyance that Netflix hasn’t completely fixed everything yet. I think this loses sight of realistic business goals of security- from an enterprise perspective one addresses security vulnerabilities in order to protect revenue or prevent damage. It is a cost benefit analysis, weighing whether allocating resources to address a particular vulnerability allows the greatest capitalization of those resources.

I’d posit that Netflix does not believe preventing CSRF attacks that add movies to the top of a queue to be the most effective use of those development resources. When looking at the impact and likelihood of this sort of CSRF attack the associated risk comes out quite low:

Impact- no direct loss of capital or resources, some level of brand damage. Some customers may very well be so pissed over getting sent some embarrassing video that they leave completely, which is a drop in revenue, however I would posit that these people are probably the minority. More people are likely to be pissed, complain, and probably get a free month as a token apology (loss of 1/12 of the yearly revenue for those people) but complaining smacks of efforts so I don’t imagine that this number will be horribly large either. Then there is the group that will be pissed and do nothing, no appreciable loss. Next is the group that is confused because they didn’t order that particular embarrassing video, no appreciable loss. Finally there is the outlier group that is hard to predict- the group where a couple gets an embarrassing movie, gets in a fight, and seperates over a movie (I live in a town where two middle aged men shot each other because of an argument over who parked their oversized SUV too close to the other oversized SUV, so I fully imagine there are people who would overreact to a movie). This might be a loss of a subscription, maintain the status quo, or a gain of a subscription because now the newly separated couple both wants a subscription, whereas they accounted for only one before.

There is also brand damage should this get media coverage once it is exploited. That is a hard thing to put dollars on.

Likelihood- For this to be exploited a customer needs to visit another website that actually carries out the CSRF attack. For that to happen the other website would need to choose actively to be malicious to Netflix instead of carrying out CSRF against a website that would allow monetary gain- there is no personal gain in exploiting this, only vandalism (which isn’t quite the correct word, but in the same spirit). The visitor needs to be logged into Netflix, and they need to be people who don’t frequently manage their queues otherwise they would notice the movie prior to it being sent (and may still react badly, but I posit that even fewer people would if they caught the movie before it shipped). Of Netflix’s 10 million subscribers I would assert that the number that would fall victim to this is small enough to be indistinguishable from zero.

Let’s look at the likely attacker- this isn’t organized crime, or any accomplished Blackhat. Those people are after money. This hypothetical attacker is likely a malcontent teenager who thinks it is funny to screw with a Netflix queue. That mostly rules out the attacker owning their own site that gets enough traffic to exploit this from, and also mostly rules out the attacker knowing of XSS or SQLi flaws in websites that do get enough traffic for this to exploit this from. It leaves their dinky website that pretty much only gets visited by their friends on IRC (or whatever script kiddies use these days)- probably some random blog on blogspot or something similar. In other news this will be exploited from a location that will not attract any noticeable number of Netflix subscribers.

So the likelihood is pretty nonexistent, the impact is very low, and thus the risk of losing subscribers because they were exploited is essentially 0. The risk of brand damage from press coverage isn’t much higher- someone in the press needs to find out about this flaw, grok what the heck the flaw really is, actually have a victim so they can tell a story about, and then compete for airtime with Company X is laying of 50,000 employees and congress is too incompetent to fix things. I predict the tampered roadsigns warning about zombies gets more press coverage. Finally the viewers need to care. TJ Max is our security story, biggest public data loss to date (with Heartland possibly taking the crown), and anecdotally the people I know who shop there weren’t even aware of it, and upon me explaining it STILL DIDN’T CARE. Netflix subscribers are a slightly different demographic, but I don’t see people getting really worked up about hearing that maybe they might be sent the wrong movie.

So why should Netflix fix this problem, instead of working on features that may attract more customers? The people who found this flaw care because it is their flaw- it matters because it is theirs. Unfortunately that doesn’t sway companies. For any vulnerability that is found it isn’t enough to point out the vulnerability- a business case also needs to be made for addressing the vulnerability. That is the reality of enterprise security- everything is cost/benefit analysis. If the risk is low, the response will reflect that. I’d love to see all vulnerabilities get addressed as much as the next security professional, but that is idealism rather than realism talking.

~ Joshbw

A paper by Adam Shostack is circulating the blogosphere, and it is worth a read. I’d already left MS before Adam took over as the gatekeeper of threat modeling for SWI but it is nice to see that he basically agrees with the stripped down version that we regularly did in WinCE and that I still evangilize. Mainly-

1) Draw a data flow diagram (DFD) of how data moves around for your application/feature (depending on scope of the model), and where trust boundries are crossed

2) Enumerate threats. The paper has a nice little matrix of what threats are pertinent to what elements of the DFD and while he applies the necessary conditionals about it being specific to MS and perhaps not being universally applicable, I think it is a pretty good reference in general.

3) Determine Mitigations (or decide to let a threat slide)

4) Validate mitigations that are put in place

We lived by those simple steps, rather than getting into the horrid threat trees and DREAD risk modeling and all of that other overhead. I say this having been the security guy for my area in MS, supposedly the expert, and I ignored them. I can’t imagine the average non-security guy going to that trouble. Granted, being a security guy I probably find it a bit easier to subjectively (wait, am I supposed to say qualititavely now that I am a CISSP?) determine risk from a threat than put a number on it, which is what the overhead in threat modeling was supposed to do, but I think most non-experts can still make an educated guess.

Anyway, the reason I am bringing all of this up is to illuminate one aspect that isn’t touched on much in most threat modeling discussion- Don’t just focus on your process/components. When people create a data flow diagram and start thinking about threats and mitigations they tend to focus on threats specific to their own code and how to mitigate stuff entering that code. However if we look at a vulnerability like XSS, it isn’t a threat to your own code, it is a threat to external entities (in this case, client browsers), and the best mitigation is to sanitize (HTML encode) data as it leaves your application rather than validate it as it enters (now you still need to validate it as it enters to make sure it isn’t malicious to your code, but don’t worry about flat out stopping xss with input validation if you can output encode).

Similarly, in the above web app example, a threat model would have us worry about how to authenticate the client for repudiation and information disclosure purposes, but I haven’t been to many threat modeling sessions where the team originaly considered the data flow the other direction (establishing to the client that this is the server you can trust- more on that in a post in the near future).

So as you are developing your threat model be sure to consider threats to each of the entities in the DFD. Don’t focus only on the flow into your components, and don’t consider threats to just your components, but rather look at the full ecology represented in your DFD.

~ Joshbw