To begin with, for those coming into the subject cold, Threat Modeling is a collection of methodologies intended to guide people through security reviews of application/feature designs to identify areas for improvement. There are a number of methodologies out there, but by far the most common is Microsoft’s STRIDE (an acronym capturing the six areas it focuses on: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege). There are other methodologies available, but for most orgs I would suggest starting with the MS approach for a number of reason. First, it has the most widespread use, and thus the most opportunity to identify weaknesses and refine the process. At MS alone hundreds of teams for the better part of a decade have been participating in Threat Modeling, and internal feedback has allowed MS to refine the process significantly (the early use of DREAD and Threat Trees to grade risk was a nightmare – ignore OWASP’s Threat Modeling page that references DREAD as it was excised from the process a long time ago). It also has the most supporting documentation externally (though steer clear of the MS Press book on the subject – it is quite dated and recommends the early overcomplicated approach that nobody should ever use), as well as several tools to aid in the process. Finally it is focused on technical design concerns in a way that approaches like OCTAVE (out of CMU) aren’t, so is much more useful to actual developers.

Conceptually STRIDE threat modeling is fairly easy. A simple Data Flow Diagram (DFD) showing how data traverses through the Application/Feature design is drawn, and then each of the STRIDE areas is applied to the model and discussion commences among the participants to identify where the design needs to be improved to protect against Spoofing, Tampering, etc. MSDN Magazine has a decent introduction to the process.

STRIDE Threat Modeling can be done in a free form manner with participants (I suggest a mix of Dev and technically proficient QA for different perspectives, with a security champion if your org has one) sitting around a whiteboard discussing the process, but it seems that most organizations gravitate to one of two tools to assist with the process. The first is the SDL Threat Modeling tool, a piece of software that MS distributes free of charge to help guide teams. Typically one or a handful of team members will sit down and draw out the DFD in the tool and catalog the actionable security improvements with the tool helping guide them to identify those improvements. The output is then reviewed by a larger audience. The tool is very competent, and while it still has a couple of rough edges and usability quirks it has improved substantially over the years. MS seems committed to continuing to improve the tool, so it should only get better. It does a fair job of prescriptively guiding the users through the process so that they don’t have to be Threat Modeling or Security Experts, though certainly experience in the area helps. It also saves all of the work in a convenient file that can be easily archived for future reference, uploaded to a central security team for review, and handed to security testers if a pen test of the product is done. The utility of that really can’t be underestimated. I would say that its biggest limitation is that the truly collaborative aspect tends to only be during a review of the finished threat model, rather than in its creation (nothing stops teams from working together on the creation, but in my experience many just assign the process to one or a handful of devs to get out of the way).

The second tool is the a fore mentioned Elevation of Privilege game. This is a very clever deck of cards that breaks each of the STRIDE elements up into a separate suite, each suite having a number of cards describing particular scenarios. For example, the 3 of Spoofing reads “An Attacker could try one credential after another and there’s nothing to slow them down (online or offline)” – if this were a website that could apply to a login page that does not rate limit the number of attempts to authenticate with a given user account. The game is played similar to Hearts or Spades with the goal of getting the most points. By default a player gets 1 point for a card that leads to a successful actionable task (for example, establishing the need of rate limiting login attempts in an application that doesn’t have them) and a bonus point if they played the highest card of the given suite for that round. I would highly suggest a modification of these rules that gives 2 points to playing the card, but 1 to anyone else who identifies an additional actionable task off the same card.

The genius of this game is that it makes the process of identifying actionable security tasks into a competition with a clear winner. I am a big fan of rewarding the winner with a $50 gift certificate to some locale restaurant or a $60 gift certificate to Amazon (because video games now cost $59.99 in the states :-)) (any security champions participating, it would probably be a good idea to exempt yourself from point accrual as that is a little unfair). If you can’t budget for something like that even a printed out award to recognize the winner goes a long way. It positively incentives folks to play and find flaws that can be improved and that is a very powerful concept. Too often security is the stick instead of the carrot, but people respond much better to carrots (or gift certificates). You will occasionally run into folks skeptical of playing a game to improve security, and it isn’t self documenting the same way that the SDL application is (and it IS important that you get the output of the game documented), but I think the gamification of security is well worth those little nitpicks.

One final word on the game – MS has provided printouts that can be taken to a printer free of charge (other than what the printer charges you). They also hand them out at their expo booths at places like the RSA security conference. Adam Shostack is encouraging someone to start a Kickstarter campaign to print the cards in volume, which I think could be a great task for OWASP (with sale of the finished product helping to fund other OWASP projects).

~ Joshbw

Depending on the org some or most of the MS SDL practices may work just fine for that org’s dev process, but there is an invisible step in the MS SDL that most orgs are missing. The Microsoft SDL fundamentally is a decision by Executive Management over development at Microsoft to CHANGE how they develop products and write code. It is a mandate to stop producing products through the old methodology and adopt the new (though it now is two methodologies – one for traditional large bundled releases and the other for iterative quick releases; mostly the same principles apply, they just apply at different points). I don’t mean to suggest that in the largest software company in the world adoption of that message is universal – certainly I suspect the recent Twisted Pixel aquisition isn’t terribly inclined to do all of the SDL work for the mobile release of Ms. Splosionman (and more importantly, it wouldn’t really matter if they did or not, given the risk profile of the app) – however by and large dev orgs at MS know that they are expected to develop apps with security as a priority, and that they may not be allowed to ship if they do not (with some pretty terrible ramifications for dev management should that happen).

I am willing to bet that the vast majority of companies are not willing to commit to security to the degree that they are willing to fundamentally change how they produce products, and by extension their dev culture. That is a huge commitment, and not one without business risk. In most cases companies know that their current dev approach works to produce products for them (whether it is the optimal way to produce products is another matter), but they can’t be confident that any radical shift in their approach will be as successful. Its basic concern for the unknown. (as an aside, I don’t think people really grok the business significance of MS being willing to go “this doesn’t work, change how we fundamentally do things” – that is a rare trait in a company, especially one of that size, and a long term competitive advantage)

If your company is not a company willing to make that degree of commitment, and odds are that it isn’t, then building security into the SDLC puts the onus on the security team and restricts the degree of change. The security team MUST be able to understand how the dev orgs produce products, what steps and methodologies they employ, and work within those constraints. Security must accommodate dev instead of the other way around, and any changes must as much as possible be transparent or integrate into existing practices. Instead of taking the approach of “You will do these new steps” it should be “Hey, I notice you are already doing these things, can I tweak that just slightly so security is also part of that step”. For example, if they already do peer code review, USE IT to also look for certain easy to spot classes of security vulns. You probably aren’t going to get them to change HOW they do code review, so there are a lot of security pitfalls they won’t catch, but you can at least get them to look for things like SQL Injection. If they already run some batch analytics on checked in code, integrate Static Analysis there, instead of making it a standalone process on each dev’s workstation. If they run some automated tests on code that is continuously deployed before it is marked public, maybe you can integrate dynamic analysis into that test suite.

The point is that the responsibility is on the AppSec person to figure out how add security into the product dev process with as little overhead as possible – all of the work lies on their shoulders (or on a delegated AppSec champion in the dev team if you have been able to get that concession – probably a different blog post, but well worth the effort to try for such an arrangement. It’s realistically the only way to scale)

~ Joshbw

• Time is not spent engineering code for re-use. It takes specific engineering effort to design a routine/function/class to be flexible enough to be re-used in similar but not identical scenarios. There is a mindset that goes into creating re-usable code that requires thought and design up front, and a whole heck of a lot of code is written off the cuff rather than designed. Decades into software development organizations *still* don’t grasp the utility of up front design sufficiently enough to drive it home as part of their development discipline. This does take time, which is money, but I contend it saves a heck of a lot of money in the long run.
• Discovering existing code that can be re-used is not easy. Even with intelliscence there isn’t a great way for a code base to advertise what functionality already exists within it. And when most people go to write a function they very rarely think “maybe I should grep to see if this already exists”. Code review by peers can help quite a bit with this, but it requires code review to be in place, which takes time
• There are a fair amount of devs that have a natural “not invented here” mentality. I don’t mean to suggest they are a majority of devs (I think the majority of devs like getting something for effectively free), but it is certainly a prevalent enough trait that it has its own label. The causes of this I think are many fold, and so the solutions likely would need to be as well
• Relating to the first point, if code wasn’t written for re-use and it *mostly* does what someone needs it to, it is often immediately faster to copy and alter it, rather than investigating what used the original code, and altering such that it fulfills both the new need and the old
• shared/re-used code is more regression prone if the person altering it does not fully understand the scope it is used in. Good automated tests are a great way of catching this

and the list goes on. I am sure folks can come up with their own reasons why we get code bloat. Now I have a couple of reasons why orgs should ACTIVELY work to restrict it. It will take up front effort, but I contend the long term ROI justifies the effort and only one of them is strictly security.

• Security: fewer lines of code are fewer opportunities for implementation vulnerabilities, a smaller attack surface (less that needs to be secured), less code to scan/code review, etc. In terms of code re-use/centralization of certain functionality it means one fix will go further, and also that it will generally be easier to find the vulnerable code to implement the fix in (a needle in a smaller haystack). If you use external consultants to help assess security, less code also directly equates to less cost for those resources.
• cheaper maintainability: There is a direct correlation between lines of code and cost of code maintenance, which should generally be obvious. There is more code to cover, more that can go wrong, it requires more effort to bring someone up to speed on the code base, etc. I think by and large companies do a terrible job accounting for the maintenance costs of their code. (as an aside, I also think companies do a terrible job tracking code churn and how much dev effort is involved revisiting specific code – i.e. would more work up front save us work in the long run)
• more efficient test coverage. it is easier to get close to 100% code coverage in QA when there is less code to cover
• less effort to improve performance, and all of you folks deployed to an IaaS provider should care quite a lot about this since every extra CPU cycle or MB of RAM is an expense you could be saving. With less code, it is much less work to profile code and track down areas with unfavorable orders of complexity, verbose object use, etc.. That doesn’t necessarily translate to it being easier to actually optimize that code – sometimes in the effort of making code flexible we do so at the expense of optimization, and at that point its a judgement call over whether the optimization gains warrant forking the code.

These aren’t trivial gains, and so while I don’t think orgs should hyper focus on code minimization, it certainly seems to make sense to give it more focus than quite a few places currently are.

~ Joshbw

• they tend to have answers that cluster; the classic is “Favorite Color” where half a dozen colors account for well over 50% of provided answers, but even larger answer sets like city of birth experience the same problem.
• the answer set, regardless of how large, is significantly smaller than even a simple password
• answers are by design re-used between any website with the same question (and there are very few websites with completely novel questions)
• answers are ambigious and prone to error – did the person answer golf or golfing for favorite past time?
• a lot of the answers are either discoverable (FB, ancestry.com, etc.) or well known by acquaintances
• answers, from the perspective of the users, may change with time if the question is poorly worded, but the stored answer in the website may not be updated to reflect the change. For example, favorite TV show (or really favorite anything) tends to reflect the sensibilities of a person at a specific period of time rather than being true independent of time of answer.

and the list goes on. Compared to all of those issues sending a message to the email or cell phone of record seems like a good alternitive (though I have always hated email based solutions given how prevelent email hijacking is – if you can’t trust the confidentiality of the destination how can you trust that it is ok to send credentials to it). A problem I have noticed is that A LOT of mobile apps have just co-opted the forgot password functionality of the website. There is a scenario where this is REALLY BAD – if the cell phone is lost or stolen. Assuming the user hasn’t set a PIN lock on the phone (and I suspect a large number of non-enterprise users haven’t) there is 0 barrier to gaining access to an account that employs email or SMS for forgot password. Where does the email or SMS terminate – the phone that is now in the untrusted hands. Companies may just accept the risk that a percentage of their user population may be compromised this way – though if they do that means that they should accept the liability of the compromised accounts instead of pushing that on the user. For those that don’t want to accept that liability some additional form of authentication external to the device (for example, shared secrets like security questions, despite how terrible they otherwise are) should be used in conjunction with the Out of Band temporary password.

Finally, companies, don’t EVER send the existing password via email or SMS. You shouldn’t even be able to if you are hashing the password like you should be doing.

~ Joshbw

While I have some issue with both that I am going to address here in a centralized fashion (rather than in the comment threads as I was originally going to do), I want to say upfront that mostly Denis is right. Devs’ fundemental job is to ship features, not security, and it’s a losing proposition to put those two things at odds (naturally with the exception of security features – a metric of an authentication feature actually working is that it provides the security assurance it promises). Now that said, I don’t think it is controversial to say that it is Devs’ job to ship features of a particular quality (as determined by the organization); we are going to have issue with a Dev that consistently introduces buggy code and fixes for that will be prioritized relative to their severity and the business need for additional features. I would assert that security is just another aspect of quality, but an aspect that is less immediately apparent or testable to most current Dev and QA orgs. It is the job of AppSec professionals to improve that particular category of quality in a way that impacts product delivery as little as possible.

I believe in a multipronged approach to doing so, of which some level of Education/Awareness, secure by default frameworks/languages, and low overhead analysis tools are all (but not exclusively) parts. And that is somewhat where I have issue with Denis as he seemed to assert that secure by default frameworks/languages mitigate the need for education/awareness, and SAST can mitigate the need for secure frameworks (so wouldn’t you just need SAST by that logic?).

(EDIT – this part removed as it is covered in a new conversation on Denis’s blog . I suspect there are minor differences of viewpoint that arise not because they actually differ but because we each see just a blog worth of the other person’s thoughts rather than the full picture)

• Low Overhead Analysis Tools – SAST/DAST (and the emerging IAST) are better than they were just a couple of years ago, but with some few exceptions they don’t integrate well into the current dev workflow. Ultimately I want SAST baked into the IDE to give feedback as near real time as possible, ideally in the form of the MS Word style spelling red squiggles under concerning code, but failing that as a part of the IDE build process. Tools aren’t quite there yet with their results accuracy to make that workable. Similarly I think DAST can be built into the QA process in much the same way as performance testing is, but only if the operational headache declines (though the SaaS guys have really worked to address that). That’s what I meant by Low Overhead; Many of the heavyweight standalone tools today are just not realistic to deploy within the average dev org or QA orgs.
• Secure Frameworks/Languages – There are security features that should just be baked into the languages and frameworks; devs should never need to know what CSRF is or implement a protection against it. Microsoft should really make their AntiXSS filter the default filter that all other filters inherit from. It really shouldn’t be possible to perform a SQL query from code unless it is in the form of a prepared statement (though granted people can still mess those up with concatination). All authentication libraries should automatically invalidate the unauthenticated session when establishing an authenticated session. Get/Post/Cookie/etc. should NOT be accessible from the same GetParameter function, but rather each have individual methods (They are different, don’t treat them as if they are the same thing). Every cookie set should automatically be Secure and HTTOnly unless disabled. etc. These all should be features that provide security for free by default to developers. The problem comes in when there is a proposed language feature that is seen as a selling feature but is less secure (AutoBinding) – at that point the exact same decision factors that play into our products will affect the team delivering their framework. The headache comes in that their security decision in turn impacts our product security and we should give them market incentive to chose otherwise.

  Lets extend this to the web servers; lets have x-frame-options locked down on every request and specifically require relaxation. Lets have SSL on by default. Etc. I’ve also posted previously that I think the W3C, in HTML 5, missed the chance to say hey, by default these security features will be enabled (CSP for example) if you declare you are using HTML 5.

  The problem with all of this though is that while hypothetically it may seem great to make this secure by default, people get pissed off when you do and that causes all of these dev products to be gun shy. MS took a lot of flack when they enabled their XSS filter in IE for all sites because it broke a lot of sites. Never mind that the sites they broke WERE doing something inherently (and blattantly) insecure. Not a lot of other folks are willing to make the same call, especially if they feel a competitor will capitalize on any outcry. We, as AppSec folks, need to try and influence our organizations to reward rather than penalize organizations making dev products so that there is market insentive to make those tough decisions. Until then it will be limited to low impact changes.

• Education/Awareness – If you look at my list of security features I think should be part of frameworks above, you see stuff I think is a waste of time to train devs on. A dev really shouldn’t have to worry about session fixation or cross site request forgery. Rather in the long term I think AppSec training should focus on secure design principles, warning flags that the security of a language/framework is being undermined (kudos for MS being blattant about this in C# with the Unsafe keyword for memory access), and the issues that really can’t be mitigated any other way realistically. We expect drivers to understand safe driving habbits despite the safety features of their car, chefs to understand proper food handling and preperation despite supply chain testing, and engineers to know how to build earthquake/fire resistent buildings. That doesn’t mean that the driver needs to understand the coefficient of friction between their brakes and wheels, or tires and road, or that the chef needs to understand the biological reaction of bacteria to cleaning solutions, or the engineer to understand the process of steel production. Those are things that should be accepted as handled by someone else. (in the appsec space, by frameworks/languages)

  The problem is that right now we can’t trust that someone else has handled that, because by and large they haven’t. Today, at this moment, we have no choice really but to make certain devs know about input validation, parameterized queries, form tokens, etc, because we are just now getting to the point where some tools are handling those for them. That sucks, but it is reality.

Anyway, I suspect where I think things should go is not terribly far from where Denis does. I suspect he would agree that some level of awarenss for security is warranted, but not to the resolution we are unfortunately stuck with today.

]]> http://www.analyticalengine.net/2012/04/approaches-to-security/feed/ 0 http://www.analyticalengine.net/2012/01/a-classic-case-of-hyperfocusing-on-one-problem/ http://www.analyticalengine.net/2012/01/a-classic-case-of-hyperfocusing-on-one-problem/#comments Thu, 05 Jan 2012 21:43:03 +0000 Joshbw http://www.analyticalengine.net/?p=272 Read More
]]> The EFF has a whitepaper advocating greater adoption of full disk encryption. The intent is to protect privacy of data during government searches or when a device is stolen. The thing is, while that is a very real risk, it is vastly overshadowed by a far more likely risk for the average user – needing to recover data from an unbootable machine. Given the general prevelence of malware it is highly likely that some form of unbootable recovery will be necessary for the vast majority of users at some point, and while it is possible to recover data from an encrypted drive the majority of solutions require opt-in action in advance to do so (for example, exporting the key to some form of removable media). When 12345 is still a common password in 2011, despite Spaceballs making fun of it decades ago, I think it is highly niave to believe that most users will have taken the appropriate steps in advance to protect themselves when needing to recover an encrypted drive.

So at this point EFF, asking for widespread adoption of encryption when the encryption solutions still aren’t really ready for consumer drive recovery is really asking to generate a much greater and more likely issue than the one you hope to solve. Sadly, such is a thing is all too common in security, where very rarely do solutions come without tradeoffs, but we often don’t consider them. Account lockout is awesome, but denial of service is not. Strong passwords are harder to break, but they are also harder to remember. And so on. One thing security folks have traditionally done a poor job with is weighing the negative effects of their solution versus the positive gains – the EFF is just the latest offender there.

~ Joshbw

]]> http://www.analyticalengine.net/2012/01/a-classic-case-of-hyperfocusing-on-one-problem/feed/ 0 http://www.analyticalengine.net/2011/12/software-engineers-versus-software-writers/ http://www.analyticalengine.net/2011/12/software-engineers-versus-software-writers/#comments Thu, 08 Dec 2011 06:47:58 +0000 Joshbw http://www.analyticalengine.net/?p=267 Read More
]]> Several years ago I worked at Microsoft and during that time I was involved in interviewing several hundred candidates. For those not familiar with the MS interview process (it may have changed) it is broken up into a number of one hour interviews where each interviewer is probing the candidate for specific qualities (not skills – qualities; a person can be taught C# but they can’t easily be taught to work well on a team). My role in the interview was typically to gauge how effective they were at actually engineering a solution – and to be specific here, the focus was not on their proficiency with a particular language; I actually asked for pseudo-code because I didn’t want the candidate caught up in worrying about syntax problems (the IDE/compiler does that for you anyway). What I was looking for was how the candidate made sure they understood the problem, and then what thought they put into designing a solution.

The problem I gave candidates to solve was the following:

• Given a string of arbitrary characters, find every sequence that was a palindrome (a sequence of characters that was the same regardless of being read left->right or right->left)
• Do NOT mark nested palindromes (i.e. one palindrome contained within another). for example aeraweabbadfrar should mark abba and rar, but NOT bb (nested within abba)
• overlapping, but not nested palindromes, should be identified. for example aeraweabbabdf should mark both abba and bab

Within 5 seconds of giving the problem I knew immediately when certain people were going to fail, because they picked up a marker and immediately started writing pseudo code on my whiteboard. They were not going to arrive at anything resembling a working algorithm. For starters, what I provided was an incomplete spec definition. Without getting into implementation specifics (like if this is C/C++ is the string null terminated or is a length param passed), here are some questions that should be asked:

• Should upper and lower case characters be considered equivalent or different?
• Are we talking only about basic Latin alphas? Do numbers count? Do extended Latin characters? Is ô equivalent to ö or are they different? Hell, are we even restricted to Latin chars?
• How should the palindromes be marked? I.e. print to screen, returned in array, written to file, etc?

The point of leaving out some details was to see if the person would just make assumptions, or if they would press me for a full problem definition. Now there is all sorts of psychology at play during an interview that could cause a person to exhibit behavior not indicative of their reaction under normal work conditions, so this alone isn’t a make or break. However asking questions to fully spec out a problem definition was a characteristic behavior of a person who was first really thinking about the problem. The other characteristic behavior was writing out a whole lot of sample inputs, covering a variety of many different input cases, to understand what sort of rules they needed to include in their logic BEFORE they started writing code. Potential variants in input included:

• even vs. odd length string
• even vs. odd length palindromes within string
• no palindromes
• one mega palindrome
• many separated palindromes (i.e. palindromes with non-palindrome characters separating them in the string)
• nested palindromes
• single and multi overlapping palindromes (e.g. cattacat has both cattac and tacat – so only a single overlap. cattacata has cattac, tacat, and ata overlapping in a series)

And so forth. If a person did not at the very least spend a good deal of time brainstorming variants of input before they even started writing a solution, they were guaranteed to arrive at a solution that failed with at least some of the above variants. In my entire time in Redmond, interviewing hundreds of candidates, exactly 3 arrived at a working, pretty much perfect algorithm. A couple more created mostly working algorithms that maybe missed one or two specific variants, or had some simple off by one errors when traversing a string that a couple of minutes at an actual debugger would have found pretty easily – I didn’t hold that against people. The vast, vast majority produced crap, and by in large they were the ones that started trying to white board code immediately.

I don’t know who to attribute the quote to, but I’ve heard it in a number of places: “Crappy programmers spend 90% of their time writing code, 10% of their time thinking; Great programmers do the exact opposite” but it pretty accurately captures the few who did well in the interview and the multitude that did poorly. I also have a different manner of thinking about the same situation – making a distinction between Software Engineering and Software Writing. People who write software largely go about it the same way I go about this blog post – they have some general notion they want to convey, and start typing until they manage to convey it. At the end it isn’t going to be particularly well structured, and could benefit from a whole lot of editing. People who engineer software go about it completely differently – in the extreme, the go about as the folks writing shuttle software go about it. Engineering is a whole lot of time spent fully understanding the problem the code tries to solve, understanding all of the conditions the code will be used in, creating blueprints for the code, documenting everything so that QA and other devs can understand things easily, and only a very little amount of time actually writing code. Engineering is a whole lot of process, and it’s a fair bit of unfun work. That’s why coders by and large prefer to just sit down and write code, and really hate when companies try and dump a bunch of process on them.

A good engineering process pays for itself though. For starters, it’s pointless to write code if it is to solve a problem or serve a function that isn’t well understood. Money is just being thrown away in that scenario (for example, in a past job I shot down a proposal by a dev team to expose error logs to end users to help debug issues when engaging support. For any number of reasons, including security, that isn’t a freaking solution, but more specifically the two real problems that needed to be solved were that enough customers were seeing issues with the product that this feature was proposed in the first place, and that the code wasn’t well instrumented enough to provide support with the error details to address the issue. Giving the customer server error logs doesn’t solve either problem but it does create new ones. I really wish I had the power to fire folks on the spot when they propose stuff like that). On top of that though, ad hoc code tends to be less reusable, more error prone, of lower general quality, less secure, harder to test, offering lower performance, and with a shorter shelf life (because of the proceeding points). You may get initial code faster if the dev just starts writing, but you also get your dinner quicker if the chef doesn’t spend time preparing it. In either case, just because it is faster doesn’t mean it is worth paying for, especially as the speed is an illusion. In the end all of the drawbacks to ad hoc code – the lower quality, increased number of errors, etc. is going to cause the dev to spend much more time revisiting that code rather than working on other things. Test passes are going to take longer. The customer is going to be less happy with the finished product, so the next version is going to revisit things from the past version instead of forging new ground.

So my plea to companies is to really focus on building a great engineering process and then enforcing it. You will produce products faster, your customers will like them more, and for folks like me it makes it a whole lot easier to bake security into development (and thus make your products more secure). It’s a really tall order to get devs to engineer with security in mind when they follow no other engineering process. Its damn easy when devs already have coding standards they follow that just need to be updated for security, when the design process is already very analytical and just needs a slight nudge to include security specific concerns, when QA is already given ample documentation to really test something and can be shown how to include a handful of security tests as well, and so forth. For companies that want to produce secure software the first question they should ask is whether or not they have a culture of software engineering or software writing. If it’s the latter, they have a lot more work ahead of them.

~ Joshbw

]]> http://www.analyticalengine.net/2011/12/software-engineers-versus-software-writers/feed/ 0 http://www.analyticalengine.net/2011/12/thoughts-on-w3c-draft-for-csp/ http://www.analyticalengine.net/2011/12/thoughts-on-w3c-draft-for-csp/#comments Thu, 01 Dec 2011 17:19:21 +0000 Joshbw http://www.analyticalengine.net/?p=264 Read More
]]> The W3C published a draft for a Content Security Policy standard, which I think is generally good news. Hopefully a full standard will get all of the browser vendors on board to finally support it (come on MS – you have otherwise tried to be at the front of the pack for security features; you created HTTP-Only, implemented a reflected xss filter, etc. Why so slow on CSP).

That said, I question how much meaningful impact this will really have, as it is an opt in security feature with fairly high implementation overhead for a lot of sites. It would have been very unpopular, but I think the right thing for the W3C to have done would have been to make same origin CSP the default for all sites declared as an HTML 5 document (<doctype html>), and require the decleration to use HTML 5 specific features. Cross origin scripts, iframe content, etc could still be explicitely enabled via header directive as specified by CSP now, but essentially the site would have to opt out of the most secure configuration rather than opt in as they do now. The incentive for devs to actually code with CSP in mind would be access to HTML 5 features – want to have access to local storage, file system API, video, etc.? Then seperate your script from your markup. (I think the same opt-out approach should be taken with x-frame-options. By default you aren’t frame-able unless you specifically attest that you are).

As mentioned, this would be very unpopular if implemented, at least initially. By five years later it would just be the way things are done, nobody would care, and the change would have done more to blunt XSS than all of the OWASP awareness, dev training, and encoding libraries combined. Buffer overflows haven’t declined because people are better at writing C/C++ – they have declined because more code is written in languages that don’t enable buffer overlows by design (though C# does have the lovely “unsafe” keyword for people hellbent on pointing a gun at their feet). If we want to see the same change for web vulnerabilities we have to similarly change the actual technologies in use to ones that make it difficult for devs to introduce vulnerabilities – starting by mandating rather than suggesting a seperation of markup and script is a step in the right direction.

~ Joshbw

]]> http://www.analyticalengine.net/2011/12/thoughts-on-w3c-draft-for-csp/feed/ 0 http://www.analyticalengine.net/2011/09/security-assurance/ http://www.analyticalengine.net/2011/09/security-assurance/#comments Wed, 28 Sep 2011 19:03:53 +0000 Joshbw http://www.analyticalengine.net/?p=254 Read More
]]> 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

]]> http://www.analyticalengine.net/2011/09/security-assurance/feed/ 0 http://www.analyticalengine.net/2011/08/blizzard-you-are-creating-problems-for-yourself/ http://www.analyticalengine.net/2011/08/blizzard-you-are-creating-problems-for-yourself/#comments Fri, 19 Aug 2011 14:48:22 +0000 Joshbw http://www.analyticalengine.net/?p=252 Read More
]]> I’ve long held that one of the best ways of securing ones’ data/functionality is by making them worthless to attackers. If SSN wasn’t the primary key to the US consumer credit system then systems could collect it without much concern, because there would be little incentive to try and compromise the system for SSNs. There are a lot of different entitities that have an interest in compromising a given system, but outside of anarchists/hacktivists (and seriously, at least in the West can we tell the difference between the two anymore?) and parties out for some form of revenge pretty much all of the other threat agents are financially motivated. If their ROI attacking your system/app doesn’t make sense they aren’t going to do it.

Given that, I can’t help but wonder if the benefits of Blizzard Entertainment’s decision to use cash transactions for In Game auctions of Diablo III are going to be worth the headache it is going to generate for them. For those who don’t understand the context of the last sentence, Blizzard is the maker of the wildly popular World of Warcraft (or WoW) and is about to release another mega-hit game. WoW already experiences extensive account compromise attacks, to the point where Blizzard actually provides two factor authentication to a freaking computer game. The reason is because they created a scarcity driven economy within their game, so there is a lot of real world money that can be made by compromising an account and selling of the possessions of the characters in the account. There are a number of hurdles that need to be jumped through to do this, but the payoff is enough that people are encouraged to do so anyway. With Diablo III they are removing many of those hurdles – instead of selling items on ebay you will be able to sell them directly in the game for cash money. In fact, you will only be able to sell them in the game for cash money – there won’t be “gold” that players can swap for items anymore. On the surface this makes a heck of a lot of financial sense – Blizzard is going to skim a fee for posting an item for auction, for bidding, and off of the final sale price. If they hit anywhere near the userbase of WoW there are going to be a lot of transactions that Blizzard is going to be skimming.

The thing is, it is also going to dramatically increase the incentive for account hijacking – if I can spend real world money in the game then that means the game must have access to my real world money. Creative thieves will be able to steal real world assets from inside a fake world, as well as the fake assets of the fake world that they can sell for real money. So I really have to wonder if it is going to be worth the headache for Blizzard – will the amount of money they make off of the auctions balance out the fallout from increasing the ROI for attackers? For the rest of us I think we are going to have an object lesson in why we should try and minimize the incentive for breaking into our apps. (or I could be wrong and Blizzard could have really engineered a system that is hard to compromise, making this whole post moot)

~ Joshbw

]]> http://www.analyticalengine.net/2011/08/blizzard-you-are-creating-problems-for-yourself/feed/ 0