<my responses inline> On Wed, Mar 12, 2008 at 6:08 PM, Benjamin Tomhave <[EMAIL PROTECTED]> wrote: > I think you misunderstood my points a little bit. SXSW was just a > current conference example. As Gary's pointed out, there are many > conferences. It's possible SXSW wasn't a good example, but it was meant > more symbolically. More comments inline...
Oh, I did miss your point. Overall, I agree. I've had mixed experiences leading me to re-evaluate my stance. A security-unaware dev friend recently told me about Microsoft coming to some conference and demonstrating this new "SQL Injection" thing to them, and he told me how amazing and cool it was. He asked if I did SQL Injection. That's the first time in several years he's responded to what I've primarily worked on for 8+ years, and incidentally for over 10, and told him about over god-knows how many Guinness. I don't blame the Guinness. (who can?) > > They just don't care. > > > > They will never care. > > > I fundamentally disagree. Everybody is the right crowd, assuming the > message is tailored appropriately. It's precisely the perspective you > espouse that concerns me greatly. I don't believe the security industry > _as_a_whole_ has maintained momentum, and I attribute that directly to > the SEP* effect. This goes directly to my larger point about ingraining > security considerations/thoughtfulness/practices into all aspects of the > business (not just coding, btw). I think this approach is doomed to failure, though my thoughts and experiences are mixed. Whilst I have quit evangelizing secure software, I do meet more and more devs interested in software security -- whom were not merely 3 to 5 years ago. Something is definitely changing, but abstract interest in appsec != secure design & implementation. While this isn't an argument -- just an observation -- I hear this "build security in" notion preached most often from the following: (a) people new to the appsec "industry" (b) academic-minded & PHD-type folks into taxonomies (c) government folks/agencies out of touch with the business world (d) eager kids just-out-of infosec college joining our "industry" (e) people with livelyhood/agendas staked on these notions Maybe I'm just jaded, but it doesn't seem to work in many, and possibly most, cases. I think the the momentum is lost because all these "build security in" and "Secure SDLC" things don't work for a lot of people/organizations. I still have some suspicions this may be due to implementation, but... This industry cannot even get it's node-hierarchies right. Even the mitre CWE is fraught with node-confusion betwixt attack nodes, vulnerability nodes, and design & implementation weakness nodes. But at the end of the day the business doesn't care. "Will this model of car sell and will we get sued over defects in it?" That's the world. If "building secure cars" was the answer Volvo would have been a wild success many, many years ago. > If everyone starts coding more responsibly, then at some point the genre > of "secure coding" goes away, because it's inherent in everything that's > written. Today, I'd settle for all externally-facing apps being coded to > address the OWASP Top 10, and to get developers to think for a change > before doing silly things like implementing client-side filtering in the > client code. Client-side filtering isn't silly. It's smart. You probably mean using it as a security control, but it's that verbiage that arms legions of the clueless appsec auditors now joining our industry that don't know sh*t about software design or implementation, or business use-case, and cause software professionals to scoff at our industry. I can't tell you how many appsec reports I've seen that say "don't use client side validation -- it's dangerous" and I start looking for more best practice nonsense listed as "vulnerabilities". "Don't allow dangerous characters in input". WTF? "Insufficient input validation". For whom? I think I see your perspective though. I think the answer is: IDEs that make it harder to shoot oneself in the foot, secure frameworks, and secure environments (for all us text-editor types) and maybe even newer languages with some real notion of a data/function boundary -- those are the keys. Leave "secure coding" out of it. Combine that with security controls that provide meaningful mis-use case and fraud detection, instead of attack-vector blocking, and you and can even allow weak password reset questions. Which is what the business, and my mother, really wants. I hesitate to say this, this is like fumbling with flame-bait, but over the last two years I feel more and more like many in this industry, including OWASP which you mentioned, are going astray down this fantasy land of secure-coding and assurance. The government (and contracting agencies by proxy) are into assurance. The rest of the world is not. The private sector is into mitigation, insurance, fraud detection and incident response. OWASP notions and directions feel to me like it's driven more and more by people out of touch with the major producers of software in the private sector, and the way the world creates and innovates software products Two things have driven this: I once was really into taxonomies and classification and clearing up the muddled mess of appsec and the utter lack of math and useless "science" that we have in this "industry". Second was a mix of learning more about the internals of Microsoft and their appsec struggles and moving out here to Silicon Valley and getting in the middle of software central. Both those things have served to push me completed over into the pragmatic camp and I look at appsec much differently now. > Hard-earned gains. How do we institutionalize these practices and get > beyond playing the role of Law Enforcement for the security department? I don't know. I don't find many real-world analogues, quite frankly. I had a sports car with a governor at 125mph once, but it was easily removable. My sport bikes will do 180mph. That's why we have LEO's. I'm not supposed to ride 180 mph on public roads. I think most devs I know look at "the art of writing secure code" like I look at a sportbike governed at 85mph: "Get out of my way". > > Overall security is not a feature or a function that you can monetarize. > > It's not even cool or sexy. It's an emergent behavior that is only > > observed when it is making your software harder to use. > > > On the first sentence, I say "yes, exactly!" On the second sentence, I > couldn't disagree more. Security should not be "making your software > harder to use." Address XSS, CSRF, SQL injection, and input/output > filtering/encoding should not diminish the end-user experience. Things > like 2-factor authentication might have that result, but we're not > really talking about that right now. I didn't say security *SHOULD* be about making your software harder to use. I said that it does, in many, many, many cases. Let's take your examples: XSS: Facebook & Myspace don't agree with you. CSRF: Everyone who has to re-authenticate. There is no other way to protect against CSRF on weakly designed auth/session controls. And re-auth sucks. Ask your mother. SQL Injection. This depends on the solution. I've seen nice, Irish, Sarah O'Grady turned into the polish Sarah OGrady or the fractal (?) Sarah O\Grady. Parameterized SQL certainly solves this neatly, but the data-function boundary concept is missing from most modern implementation-level languages. So you can't solve XSS that way. > > Not until insurance or substantial penalties are the norm (if they are > > ever the norm) will we have meaningful quantitative data to drive a > > justification for security as a requirement in startup or most open > > source software projects. That's my opinion, anyway. > > > I would really like for you to be wrong, but I can't really disagree > with your base conclusion here. Hence my frustration. It provides a good > case for shelving all security departments until the business starts > taking major hits and they come begging for help. Honestly, I don't > understand it. Businesses don't disagree that they need properly secured > code/sites/etc. Yet, by the same token, they don't do what's necessary > up front to secure their code/sites/etc. It's a truly bizarre disconnect > that boggles my mind. It's not a disconnect my man. It's reality. Businesses don't ship code to show off Secure Software. They ship code to make money. Software security is an emergent behavior that changes over time with software use, evolution, extension, and the changing threat landscape. It's not an art you get people inspired in. Take the threat landscape: Phishers are just starting to use XSS in ernest now. No one knows what in the world is really out there that we are facing, except maybe IBM's Global Managed network services (who is starting to monitor and measure this stuff now). They probably have the biggest sample of real-world traffic. I know folks at a number of large software companies/websites out there on the 'net that face regular attacks and have a decent idea what real attacks are and what dealing with them costs, but they are all private sector and none of them are going to release anything in the way of data about it. Releasing facts might raise their cost of business. > Thanks for the response! :) You too. Yours was well reasoned; I still disagree on points though. A third thing I'll add -- my employer for the last 1.5 years has enabled me to see about 500-600 production websites, and their vulnerability posture from a black-box perspective, but also how people fix things, what they fix, why, what they assume the risk on, etc., and have my customers tell me what is attacked and how. Having that much real-world data has also changed my perspective from a once-purist "design & write more reliable code" and "look at your code, fix your code" to more of a "this is how the world is; let's make better band-aids cause we're always going to need them" view. I've been meaning to write an essay on Idealogies and Idealogy Wars in appsec. There's at least three major idealogue camps, and wars between them starting to brew, but most folks new to this field have no idea what the agendas and perspectives are, why they exist, and what drives the different ideals. Thanks for the stimulating though, ciao -- Arian Evans software security stuff _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
